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FOREWORD 


This final report covers the work performed by Autonetics Division of 
North American Rockwell Corporation under a study contract entitled Analysis 
of a Display and Control System Man-Machine Interface Concept. The report 
is submitted to the National Aeronautics and Space Administration Manned 
Spacecraft Center under the requirements of Contract NAS 9-12266. The study 
program covered the period from October 1, 1971 through August 31, 1972. The 
NASA technical monitor was Mr. G. K. Raines. 

The final report consists of four (4) volumes: 


—►Volume I. Final Technical Report 

Volume II. Appendix A. Principal Subsystems 

of Phase B Orbital Vehicle used in 
the Analysis. 


Appendix B. Control and Display Data 
Required for Crew Operations. 

Volume III. Appendix C. Formats and Format Trees 

Appendix D. Coding of Sample Format 

Appendix E. Principal Subsystems of 
NR-SD Winning Proposal Orbital Vehicle 


Volume IV. Appendix F. Control/Display Sequences 
for Four Mission Phases 


-►You are reading this volume. 
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1.0 INTRODUCTION 


1.1 OBJECTIVE 

The objective of this study was to evaluate the feasibility of utilizing 
a simplified man-machine interface concept to manage and control a complex 
space system involving multiple redundant computers that control multiple 
redundant subsystems. The concept under evaluation involved the use of a CRT 
for display and a simple keyboard (numerics and function switches, no alpha- 
betics) for control, with a tree-type control logic for accessing and con- 
trolling mission, system and subsystem elements. 

Demonstration of concept feasibility was contingent upon preliminary defi- 
nition of display formats and keyboard functions required, the control logic 
tree to be utilized, control and display software needed and potential problem 
areas encountered with this approach. Additional support was required through 
demonstration that the crew could effectively monitor and manage the system 
during critical mission phases without compromising mission success or crew 
safety. 

To provide an effective test of the concept, the Orbital Vehicle of the 
Space Shuttle System was selected for analysis. The concept was evaluated 
in terms of the Phase B Space Shuttle System Design Study Orbital Vehicle, 
to utilize the wide scope of data management and subsystem control inherent in 
the central data management subsystem provided by the Phase B design philosophy. 
Following evaluation of the feasibility of the control/display concept with 
that system, a limited supplemental study was performed to evaluate feasibility 
with the North American Rockwell Space Division (NR-SD) winning proposal con- 
figuration. This was to determine the effectiveness of the concept with a 
system exhibiting much more limited central data management and control and 
providing a much greater utilization of dedicated cockpit instrumentation. 

1 . 2 WORK ACCOMPLISHED 

The study was performed in five phases: (1) establishment of control/ 

display functional requirements, (2) development of control logic concepts, 

(3) preliminary design of control/display processor/software , (4) determina- 
tion of concept impact on the DMS and problem identification, and (5) appli- 
cation of concept to the NR-SD winning Shuttle design. The following is a 
brief summary of the work performed during each phase. 

1.2.1 Control/Display Functional Requirements 

Phase B Space Shuttle Orbital Vehicle design specifications and descrip- 
tions were utilized to identify (1) mission characterisitcs, including a detailed 
mission time schedule, (2) vehicle/subsystem characteristics requiring control 
and display interfaces, (3) total information and control requirements, and 

(4) mission-specific crew tasks, for both nominal and non-nominal mission phases. 
A preliminary control and display logic concept was developed. Utilizing this 
and the information and control requirements, sample display formats were 
developed for mission and subsystem management. Approximately 100 formats were 
developed, representing 20 percent of the estimated total format requirement. 

Crew workload requirements were estimated, based on timeline analyses of selected 


1-1 



mission phases, with the crew utilizing the preliminary control and display 
design concepts and sample display formats. Total display and control require- 
ments were estimated on the basis of the above analyses. 

1.2.2 Control Logic Concepts 

A control logic tree was developed, to permit crew access to any display 
format in the system, utilizing no more than two indexes. Control and display 
sequencing for both crew members, utilizing all five CRT displays and three 
keyboards, was diagrammed step-by-step for four mission phases, to illustrate 
how data and commands are entered into the computer and to verify the utility 
of the control and display concept to the crew. Keyboard functions were com- 
pletely defined. 

1.2.3 Preliminary Design 

Two alternate display /processor/software designs were developed and defined 
in detail, including mechanization, hardware requirements. The major difference 
between the two design concepts was in the method of display generation -- one 
utilizing a complex random stroke generation technique, the other using a less 
complex dot matrix generation technique. Estimates of mass-memory and processor 
storage and speed requirements were generated for each of the two design concepts. 
Program modules for all display and control operations were identified and des- 
cribed. Feasibility of both design concepts was verified. 

1.2.4 Impact and Problem Areas 

The impact of the two alternate design concepts on the central Data Manage- 
ment System was assessed and found to be primarily in the area of mass memory 
requirements. Problems associated with the implementation of the design con- 
cepts were identified, as well as problems associated with crew utilization. 

1.2.5 Application to NR-SD Winning Shuttle Design 

In a limited supplemental study following completion of the main study 
work described above, the NR-SD winning proposal configuration and the NASA 
proposal mission were reviewed to select representative subsystems for concept 
application evaluations. A mechanization approach and a preliminary design 
for concept application were defined. Three computers, two mass memories and 
a large number of command decoders were added to incorporate the concept. 

These additions were required since the NR-SD design utilizes dedicated controls 
and displays and does not include a central data management system. 

Due to the significant quantity of added hardware/software, the control 
and display concept does not appear attractive for the NR-SD design. 

This supplemental study is reported in Section 7.0 of this report. 


1.3 REPORT CONTENT 

Sections 2.0 through 6.0 report only the main study (Phase B shuttle con- 
figuration). Section 2.0 presents summary and conclusions. Section 3.0 des- 
cribes the control and display functional requirements. Section 4.0 covers 
control logic. Section 5.0 covers preliminary design and Section 6.0 describes 
DMS impact and problem identification. 
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Section 7.0 reports only the supplemental study (NR-SD winning shuttle 
configuration) . 
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2.0 SUMMARY AND CONCLUSIONS 


2.1 BASELINE ASSUMPTIONS 

Assumptions made concerning the baseline system design fall within three 
major areas: (1) human performance capabilities and limitations, (2) SSV 

program, mission and vehicle constraints, and (3) control and display guide- 
lines . 

2.1.1 Human Performance Capabilities and Limitations 

Design of SSV system and subsystem equipment, GSE and component arrange- 
ment was assumed to be in conformance with established human engineering design 
criteria. Design of the DMS control and display concept used in the study, and 
the logic and procedures for its utilization, conform also to established human 
engineering design criteria. 

Primary source for established human engineering design criteria was 
MIL-STD-1472, Human Engineering Design Criteria for Military Systems, Equipment 
and Facilities. Performance data relating to human capabilities and limita- 
tions not covered by applicable portions of MIL-STD-1472 were obtained from 
standard human engineering texts , MSC inhouse and sponsored studies and from 
Autonetics human engineering experiments and studies. 

2.1.2 SSV Program, Mission and Vehicle Constraints 

The Phase B Space Shuttle Orbital Vehicle design was selected as the base- 
line system for evaluating the control and display concept. The only changes 
made in the Phase B design were those necessary for incorporation of the 
control and display concept. 

The orbiter was assumed to have a two-man flight crew, to be flyable under 
emergency conditions by a single crewman, and to have landing characteristics 
and handling qualities requiring no more demanding skills than those required 
for operational land-based aircraft. Normal operation was considered automatic, 
but the flight crew was provided the capability to control the space shuttle 
through all flight phases. 

The MSS Logistic Resupply Mission was selected for the detailed analysis. 
Functions relating to docking and cargo handling were not included in the 
analysis because they are performed from a separatecrew station. It was concluded 
that the MSS Logistic Resupply Mission is completely representative of all other 
Space Shuttle Missions with respect to its control/display requirements. 

2.1.3 Control and Display Guidelines 

The baseline control and display subsystem used in the study consists of 
5 CRTs and 3 keyboards, with a limited number of dedicated displays and controls 
identified by the study. With the exception of the few dedicated displays and 
controls, all information necessary to the monitoring and control of the mission, 
vehicle and subsystems is available for display on the CRTs and all control 
actions involved in selecting displays, entering data, initiating control sequences 
and controlling discretes can be performed from the numeric keyboard and its 
associated function keys. 
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The CRT display system is capable of displaying computer generated alpha- 
numerics and graphics, including (1) primary and secondary flight displays for 
all vehicle modes, i.e., attitude, air data, horizontal situation, GN§C and 
GCS, communication control, engine data, (2) subsystem status and control, (3) 
dedicated display backups, and (4) checklists, mission rules, texts, etc. 

The display generator accepts data from an I/O controller, transforms this 
data into a form suitable for use by the CRT monitors, and refreshes the dis- 
play at a rate sufficient to produce flicker-free display on the CRT. 

No memorization of operational codes is required of the crew; the control 
functions available in any configuration are adequately displayed on the 
associated CRT. The multipurpose keyboard panels provide the capability for 
controlling all subsystem functions, including communication and navigation 
frequency selection, IMU control, GN§C control, auto-pilot control backup and 
display accessing. 

2.2 CONTROL AND DISPLAY CONCEPT 

The control and display concept developed during the study permits the 
crew to monitor and control nearly all mission operations using only the CRTs 
and keyboards. Operations performed at remote stations and certain non-nominal 
activities (e.g., manual flight control) require dedicated controls, but all 
nominal and most non-nominal tasks utilize the control and display concept 
described below. 

All information pertaining to mission, vehicle and subsystem operation 
is contained in at least one of an estimated 500 specially designed display 
formats. Each format contains numeric codes necessary for exercising control 
over the system element with which it deals as well as accessing codes for 
calling up other formats. Display formats are of three basic types: (1) 

operational procedures, (2) mission timelines, and (3) system management. 

Operational procedure formats are checklists, displaying task-relevant 
quantitative data, instructions and options. The checklists are sequenced 
by numeric keyboard entries used to perform each task. 

Mission timeline formats assist the crew in pacing checklist operations, 
permit integration of the two crew members task activities and provide overall 
visibility of mission operations as a function of time. Mission timeline formats 
are automatically displayed, as a function of mission time, during nominal mission 
operations. 

System management formats include subsystem schematics , tabular control 
formats, tabular status formats, data entry formats and vehicle management 
formats. Subsystem schematics are diagrammatic representations of all compo- 
nents operable by the crew, as well as other important components necessary 
for crew understanding of the working of each subsystem element. Tabular 
control and status formats are tabular listings of available control commands 
and system status, unsuitable for schematic representation, but grouped 
according to functions or subsystem. Data entry formats permit the entry of 
numeric data into the computer, e.g., alternate landing site coordinates, 
navigation data, etc. Vehicle management formats provide monitoring and 
control of vehicle flight parameters, modeled after standard aircraft instru- 
mentation and Apollo instruments. 
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. Access to individual formats is provided by a control logic tree consisting 
of a master index and groups of sub- indexes. The logic tree is designed to 
provide access to any format by reference to no more than two indexes. Rapid 
access features are provided to permit direct accessing of related or important 
formats from any single format. 

All control operations (except those few requiring dedicated controls) 
are performed with the 0-9 keyboard and a limited number of special function 
keys. Five special function keys permit connecting any keyboard to any of the 
CRTs, although no two keyboards may be connected simultaneously to a single 
display and no keyboard may be connected to two displays at one time. Additional 
special function keys permit entering and clearing commands, increasing and 
decreasing variable functions, designating data sign or direction (navigation 
coordinates) and authorizing a computer -recommended display shift. 

Control commands and display accessing commands are entered by numeric 
codes -- 1-digit codes for rapid access commands, 2-digit codes for control 
commands and 3-digit codes for display format call-up. Control command codes 
are displayed next to the components they control on subsystem schematic for- 
mats or next to the component or function name on tabular formats. The dis- 
played codes are brightness- coded to indicate the last transmitted command and 
component symbols are position- coded (or size-coded) to indicate their present 
sensed state; thus, diagnostic capabilities are inherent in the concept design. 

2.3: PRELIMINARY DESIGN 

Two alternate display techniques were mechanized and evaluated for appli- 
cation to the control and display concept under study. Both approaches were 
designed to interface with the Phase B integrated Data Management System (EMS) 
concept; i.e., a centralized computing complex interconnected with the various 
onboard subsystems by a data bus subsystem. Additionally, the centralized 
mass memory was used for the off-line storage medium. Both techniques are 
considered to be feasible. 

The major difference between the two approaches is in the method of 
display generation. The first method used the more sophisticated random 
stroke technique while the second method used a less complex dot matrix 
approach. Additionally, the second method used a 16-bit display control word 
structure, as opposed to the first method which used a 32-bit control word 
structure. 

Both designs were evaluated to a level of detail sufficient to establish 
feasibility. Neither design was completely optimized; however, examination 
of two approaches provides increased data for the conclusions. 

As a result of the preliminary design effort and analyses, relative 
differences between the approaches are apparent. The dot matrix method 
eliminates the electrostatic deflection (superimposed on electromagnetic 
deflection) of the random stroke technique. The need for multiplexing at 
the interface between the display processors and the display controller is 
more critical for the dot matrix method. This is primarily attributable to 
the increase in the number of control words required because 16 bits rather 
than 32 bits are used. A 12 percent savings (approximately 200,000 32 -bit 
words including allowance for 100 percent design reserve and triple redun- 
dancy) is realized with the 16 -bit dot matrix structure in comparison with 
the 32 -bit design. 
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Conversely, a definite savings in the number of instructions per format is 
realized using the 32-bit control word. This would normally translate directly 
into a savings of programming dollars . A complete tradeoff between the two 
design approaches is beyond the scope of this study. 

The most significant impact on the IMS, of the control/ display design 
concept, is the increase in mass memory sizing, from the 400K 32 -bit words 
of the Phase B design to 800K 32-bit words. This sizing includes a 100 
percent reserve allowance and is for each of the three storage units of 
the triple redundant storage system. An additional, but less important, 
impact is the need for a direct access channel between the mass memory 
and the display processor. This is required primarily to reduce the 
response time between selecting a format and having it displayed. A 
definite software impact is realized due to the increase in the programming 
requirements demonstrated by the large number of formats required ; i . e . , 
approximately 500. 


The results and conclusions stated above are based on having automated 
the on-board operational checklist. It is interesting to point out the differ- 
ences in requirements had the checklist been contained in a printed manual 
typical of the Apollo program, but instrumented through the use of the operator 
to keyboard interface. First, a reduction of approximately 160K 32-bit words 
would be realized. This translates directly into a 50 percent reduction in 
the mass memory add-on and a reduction of approximately 40 percent in the pro- 
gramming requirements. On the other hand, little or no reduction is realized 
in the display hardware itself. The actual merit of automating the checklist 
is out of scope of this study. 

The evaluated control and display concept is feasible and desirable for 
a shuttle vehicle of the Phase B design philosophy which features an integrated 
control data management system. 

(The summary and conclusions of the supplemental study to examine feasi- 
bility of concept application to the NR-SD winning proposal configuration are 
reported in Section 7.6.) 
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3 . 0 CONTROL AND DISPLAY FUNCTIONAL REQUIREMENTS 


3.1 OVERVIEW 

The purpose of this analysis phase was to develop control and display 
requirements in sufficient detail to permit (1) verification of crew capa- 
bility to handle nominal and non-nominal operations during selected mission 
phases, (2) estimation of total quantities and types of control and display 
requirements during an entire mission, and (3) development and validation of 
a display logic concept using the proposed keyboard-CRT control /display sub- 
system. This section describes the procedures and results of the control and 
display functional analysis. 

The steps described herein include development of a baseline mission, 
together with mission timelines, determination of vehicle and subsystem 
characteristics, establishment of mission functions, definition of crew 
information/action requirements, development of control and display require- 
ments, selection of mission phases for detailed analyses, workload analysis 
and total requirements estimation. 

The analysis utilized contractor-furnished descriptions of the missions, 
vehicle and subsystem characteristics for the Orbital Vehicle resulting from 
the Phase B Space Shuttle System Design Study. The only changes made in the 
Phase B design were those necessary for implementation of the Display and 
Control System design concept. 

3.2 BASELINE MISSION 

Space shuttle missions were examined to identify a representative mission 
suitable for the determination of control/display requirements. Missions 
examined included (1) Modular Space Station (MSS) Operations, (2) Earth 
Resources Survey, (3) Geosynchronous Satellite Emplacement, (4) Sun-synchronous 
Satellite Operations and (5) Space Station Rescue. The MSS Logistic Resupply 
Mission was selected for analysis. As shown in Figure 3-1, it includes the 
functions of ascent, rendezvous, docking, on-orbit resupply, deorbit, entry 
and landing. 

Each of the other missions was reviewed to determine whether it requires 
functions or tasks not required by the MSS Logistics Resupply Mission. During 
the review, functions relating to docking and cargo handling were ruled out 
since, in the Phase B design, they are performed from a separate crew station 
and do not directly impact the main control/display subsystem. The other 
missions, with the exception of Space Station Rescue, differ from the MSS 
Operations primarily in orbital inclination, number of phasing burns required, 
orbital altitude and types of payload to be handled. Tasks required for 
establishing the orbital parameters are the same as for the MSS Logistics 
Resupply Mission, although they may be performed more or less frequently, and 
they will use the same data parameters, although with different parametric 
values . 
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Figure 3-1. MSS Logistic Resupply Mission Selected for Analysis 



Thus, it was concluded that satisfaction of the control and display 
requirements of the baseline MSS Logistics Resupply Mission would also satisfy 
the requirements for all other shuttle orbital missions. 

3.3 MISSION TIMELINE 

A mission timeline was developed for the baseline mission based on 
elapsed time estimates provided in the Phase B study for each of the mission 
phases. The timeline, shown in Figure 3-2, shows major events programmed for 
each mission phase. The time between each of these events was assumed to be 
the time available for the crew to perform necessary manual control tasks and 
to monitor system performance. During later analysis tasks (critical phase 
selection, workload analysis) , these timelines were used to determine the 
mission phases involving the heaviest crew workloads and to verify that ade- 
quate time would be available to use the control and display design concept. 

In constructing the timelines, no delays or stopover times were con- 
sidered, such as the payload transfer period at the space station or the 
waiting period during stationkeeping. During these periods, it was assumed 
that the control and display subsystem would be in operation only for 
periodic status checks, and thus these periods would not materially impact 
control/display design. Under this constraint, total mission time is 33 
hours. 

Each event on the timelines represents a point in the mission at which 
one series of operator tasks must be completed and a new series begun. In 
general, major events, such as Delta V bums, are preceded by a series of 
configuration tasks and followed by a series of reconfiguration tasks. It 
is assumed that all tasks between two events must be completed by the crew 
for the later event to take place. Thus, to be feasible for the mission 
operations considered, the display and control concept must enable the crew 
to perform all assigned tasks within an event pair. Demonstration of this 
feasibility is described in Section 3.9,’ Workload Analysis. - 

3.4 VEHICLE AND SUBSYSTEM CHARACmaSTIC^ . 

The Phase B orbiter, as described in Report MSC-00 37 , "Phase B Final 
Report, Volume II Technical Summary, Book 2, Orbiter Vehicle Definition" 

(SD 71-114-2) , was used as the basic vehicle configuration. Diagrams of 
the principle subsystems are provided in Appendix A. • . . 

Certain constraints were observed, during the study, aimed at circum- 
scribing the scope of the analysis within reasonable limits. The constraints 
are described below. . . .. ■ .*.•_ • ... 

Only orbiter vehicle functions are- included in the analysis. It was 
assumed that the booster vehicle would be. manned and that during mated ascent 
only monitoring and staging preparation . tasks would be performed by the 
orbiter crew. 

Within the orbiter, only functions associated with the main cockpit 
controls and displays were analyzed. It was assumed that docking and payload 
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1.9.6 UMDOCK 



3-6 


CDH Maneuver (to circ 260 rrai) (1.9. 1.5) 
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Perform 'atmospheric/powered flight checkout (1.16.2) 

A Configure orbiter for atmospheric flight (1.16.4) 

Perform program of descent maneuvers (400K ft - 40K ft) (1.16.3) 
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Establish missed approach attitude (1.19.3) 

Configure vehicle for climbout (1.19.4) 

/V Complete missed approach pattern (1.19.6) 



management functions would be performed at a separate -crew station; therefore 
these functions were not included in the analysis. . 

. The orbit er was assumed to have a two-man flight crew and to be flyable 
under emergency conditions by a single cr ewman . 

Landing characteristics and handling qualities were assumed to require 
skills no more demanding than those required for operational land-based 
aircraft. ' . ‘ 

Provisions were made for crew- initiated override of all automated 
critical control functions. , • , >. . ; • .. 

Provisions were made for crew initiation of all abort modes. 

The orbiter was assumed to have powered go-around capability and to be 1 
capable of making either a powered or unpowered approach and landing . For 
purposes of the analysis, the more highly task-loaded powered flight con- 
figuration was assumed. ■ • • 

In-flight maintenance was assumed not to be .required although checkout 
and fault isolation capabilities of the Phase B concept were incorporated 
in the study. 

Reliability requirements for the overall system were assumed to be .999 
probability of crew safety, 0.9 minimum probability of completing the design 
reference mission. 

No single point failures were permitted which would result in loss of 
the vehicle or crew. 

All subsystems , as a minimum, were assumed to be designed to fail opera- 
tional after the failure of the most critical component and to fail safe for 
crew survival after the second failure. This assumption was met with the 
control and display subsystem concept design. 

In systems where redundancy is needed, the space shuttle system was 
assumed to provide redundancy within the system itself rather than providing 
degraded performance backup system concepts. 

The control and display system was designed to support vertical launch 
as well as typical aircraft horizontal takeoff and landing. 

Within the DMS , automatic failure isolation and recovery was assumed to 
not require coping with the problem of two or more simultaneous failures. 

The DMS was assumed to be designed to allow manual specification of the 
level of redundancy within the computer system. Provisions for this were 
incorporated into the control and display concept design. 

Provisions were made for the crew to manually specify the DMS configura- 
tion and thus override all automatic fault isolation and switching functions. 
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Normal operation was assumed to be automatic through all mission 
phases, but the flight crew was provided the capability to control the 
orbiter through all flight phases . When required , the flight crew would be 
able to participate in navigation, control, monitoring, computing, and 
observation of all subsystems. Status of subsystems would be displayed for 
crew monitoring, failure detection and operational mode selection. 

The crew environment was assumed to be shirtsleeve. Therefore, no 
provisions were made in the displays and controls for operation with pressure 
suit on. 

The overall system design provides the capability to display to the 
crew independent information from redundant data sources and selected data 
processing . 

The subsystems to be monitored and controlled by the control and display 
system concept include (1) Environment. Control- and Life ' Support , (2) Power 
Generation Distribution and Control, (3) Propulsion, (4) Data Control and 
Management , ( 5 ) Guidance , Navigation and Control , (6) • Communications , ( 7 ) 
Displays and Controls, (8) Caution and Warning, (9) Checkout and Fault 
. Isolation, and (1) Consumables. • ; • 

3.5 MISSION FUNCTIONS AND ALLOCATION TO CREW • ' is 

The Phase B orbiter mission descriptions in MSC-03310, "Operations Plan 
for Phase C/D"‘ (SD 71-103-2) were used as .a source document for selecting 
mission functions. Selected mission functions are listed in Table 3-1. Each 
function retains the number designation used in the Phase B functional flow 
• charts to permit cross reference between the data source and the analysis. 
Only functions involving crew/ system interfaces were selected and only those 
functions dealing with orbiter vehicle control and management were considered. 

Mission functions /subfunctions were . examined to determine the degree 
of crew participation planned for in the Phase B design . This level of crew 
participation was adhered to throughout the analysis, with the exception of 
functions relating directly to the control/display concept under study. 
Preliminary assignments of crew functions to the Commander (CDR) and Pilot 
(PLT) were made to assist in subsequent task analyses. However, these 
preliminary allocations were deviated frcm in the final task timelines 
whenever such changes would result in better utilization of available time. 

No effort was made to conform to any set pattern of function allocations 
to either crew member because it was assumed that each crew member must be 
competent to perform all mission tasks (one-man emergency operation ground 
rule). The preliminary crew allocation is listed in Table 3-2. 

3.6 INFORMATION/ ACTION REQUIREMENTS 

Crew requirements for mission, system and subsystem data and for control 
capabilities were derived from an inf ormation/decision/action analysis 
developed mainly from two sources. Each primary subsystem was analyzed to 
determine what controllable elements are available within the subsystems 
(switches, valves, etc.) and what sensor or status data are available from 
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Table. 3-1. Mission Functions Selected for Analysis 


PHASE 



I. 

Pre-mission Preparation 



A. Perform premate checkout 

2.4 


1 . Insert software 

2.4.1 . 


2. Energize systems 

2.4.2 


3 . Perform checkout 

2.4.3 


B. Perform vehicle erection and assembly 

2.1 


1. Prepare orbiter for mating 

2.1.2 


a. load flight program 

2. 1.2. 2 


b. verify flight program operation 

2. 1.2. 3 


c. clear flight and engine recorders 

2. 1.2. 5 


2- Mate orbiter to booster 

2.1.4 


a. verify orbiter to booster interfaces 

2. 1.4. 2 


b. verify orbiter/ launcher interfaces 

2. 1.4. 3 


C. Transfer and install at pad 

2.2 


1. Conduct launch readiness checkout 

2.2.3 


a. check out flight control systems 

2. 2. 3.1 


b. check out GN&C systems 

2. 2. 3. 2 


c. check out power systems 

2. 2. 3. 3 


d. check out communications systems 

2. 2. 3. 4 


e. check out propulsion systems 

2. 2. 3. 5 


f. perform switch scan 

2. 2. 3. 7 


2 . Attain standby status 

2.2.4 


a. place flight systems in standby 

2. 2. 4.1 


b. monitor shuttle status 

2. 2. 4. 2 


c. activate flight systems 

2. 2. 4. 8 


d. update software with final parameters 

2. 2. 4. 9 


e. verify circuits and arm ordinance 

2.2.4.10 

II. 

Launch 



A. Perform launch operations 

2.3 


1. Perform propellant loading 

2.3.1 


a. monitor vehicle systems 

2. 3. 1.2 


2. Complete final system activation 

2.3.5 


3. Perform launch countdown 

2.3.4 


a. verify displayed checklist 

2. 3. 4.1 


b. verify GNSC alignment 

2. 3. 4. 2 


c. transfer to internal power 

2. 3. 4. 4 


d. verify all subsystems ready 

2. 3. 4. 5 


e. verify shuttle ready for launch 

2. 3. 4. 9 


f. perform launch program 

2.3.4.10 


B. perform mated ascent 

1.1 

.. 

1. Perform initial ascent maneuver 

1.1.1 
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FHASE 

a. monitor engine performance 

1.1. 1.6 


b. monitor orbiter vehicle propellant pressures 

1.1. 1.7 


c . monitor lift-off 

1.1. 1.1 


d. monitor time from lift-off 

1.1. 1.5 


2 . Perform roll maneuver 

1.1.2 


a. maintain pitch and yaw null attitude 

1.1. 2.1 


b. monitor roll program 

1.1. 2. 2 


c. determine roll rate 

1.1. 2. 3 


d. determine roll error 

1.1. 2. 4 


e. generate roll command 

1.1. 2. 5 


f . execute roll command 

1.1. 2. 6 


g. monitor time from lift-off 

1.1. 2. 7 


3 . Perform pitch maneuver 

1.1.3 


a. maintain roll and yaw null attitude 

1.1. 3.1 


b. monitor pitch program 

1.1. 3. 2 


c. determine pitch rate 

1.1. 3. 3 


d. determine pitch error 

1.1. 3. 4 


e. generate pitch command 

1.1. 3. 5 


f . execute pitch command 

1.1. 3. 6 


4. Maintain ascent profile 

1.1.4 


a. maintain gravity turn 

1.1. 4.1 


b. maintain 3-g axial acceleration limit 

1.1. 4. 2 


c. maintain roll and yaw null attitude 

1.1. 4. 3 


d. activate booster attitude control propusion 
system 

1.1. 4. 4 

C. 

Perform booster/orbiter staging 

1.2 


1. Sense booster propellant depletion 

1.2.1 


a. transmit signal to booster and orbiter DCM 

1.2. 1.3 


2. Configure vehicles for staging 

1.2.2 


a. initiate stagin sequence 

1.2. 2.1 


b. perform orbiter engine stagin program 

1.2. 2. 4 


c. activate orbiter attitude control propulsion 
subsystem 

1.2. 2. 5 

B. 

Perform separation 

1.2.3 


1. Increase orbiter thrust to 100% nominal power 

1.2. 3. 4 


2. Maintain orbiter attitude 

1.2. 3. 5 


3 . Perform physical separation 

1.2. 3. 6 

Ill . Orbital Insertion 


A. 

Achieve initial earth orbit 

1.8 


1. Stabilize orbiter on ascent trajectory 

1.8.1 


2. Control trajectory to injection 

1.8.2 


3. Perform injection maneuver 

1.8.3 
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Table 3 -1 . ( Cent . ) 


PHASE 




IV. 

Rendezvous 



A. 

Perform Space Station/base logistics support 

1.9 



1. Perform orbit and phase changes 

1.9.1 



2 . Rendezvous with Space Station 

1.9.2 


B. 

Perform placement and retrieval of payload 

1.10 



1. Perform orbit and phase changes 

1.10.1 



2 . Maneuver to emplace payload 

1.10.2 



3 . Configure shuttle for alternate mission 

1.10.12 



4. Perform orbit and phase change 

1.10.13 



5. Rendezvous with payload 

1.10.20 


c. 

Perform delivery of propellants 

1.11 



1. Perform orbit and phase change 

1.11.1 



2 . Rendezvous with other orbiting body 

1.11.2 


D. 

Perform short duration orbital mission 

1.12 



1. Perform orbit and phase changes 

1.12.1 



2 . Configure shuttle for alternate mission 

1.12.7 



3 . Perform orbit and phase change 

1.12.8 

V. 

Dock 



A. 

Perform Space Station/base logistics support 

1.9 



1. Dock with Space Station 

1.9.3 


B. 

Perform placement and retrieval of payload 

1.10 



1. Couple /dock to payload 

1.10.24 


c. 

Perform delivery of propellants 

1.11 



1. Dock with orbiting body 

1.11.4 

VI. 

Undock 



A. 

Perform Space Station/base logistics support 

1.9 



1 . Undock 

1.9.6 


B. 

Perform placement and retrieval of payload 

1.10 



1. Uncouple/undock from payload 

1.10.6 


c. 

Perform delivery of propellants 

1.11 



1. Undock from other orbiting body 

1.11.7 

VII. 

Stationkeep 



A. 

Perform Space Station/base logistics support 

1.9 
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PHASE 


VIII. 


IX. 


X. 



1. Separate to safe distance for stay 

2 . Stationkeep during stay 

3 . Separate to safe distance from space station 

1.9.7 

1.9.8 
1.9.11 

B. 

Perform placement and retrieval of payload 

1.10 


1. Separate safe distance from payload 

1.10.7 

C. 

Perform delivery of propellants 

1.11 


1. Separate safe distance from other orbiting body 

1.11.8 

D. 

Perform short-duration orbital mission 

1.12 


1. Configure shuttle for earth resource survey 
2 • Configure shuttle for equipment tests 

1.12.4 

1.12.3 

Deorbit 


A. 

Perform Space Station/ base logistics support 

1.9 


J. Perform on-orbit phasing 

1.9.12 

B. 

Perform placement and retrieval of payload 

1.10 


1. Configure shuttle for earth return 

2. Perform on-orbit phasing 

1.10.27 

1.10.28 

C. 

perform delivery of propellants 

1.11 


1. Configure shuttle for earth return 

2. Perform on-orbit phasing 

1.11.9 

1.11.10 

D. 

Perform short -duration orbital mission 

1.12 


1. Configure shuttle for earth return 
2 • Perform on-orbit phasing 

1.12.5 

1.12.6 

E. 

perform deorbit maneuvers 

1.15 


1. Configure orbit er for deorbit 

2 . Perform retro maneuver 

1.15.1 

1.15.2 

Entry 


A. 

Perform orbiter entry 

1.16 


1. Establish entry and maintain desired entry 

2. Perform program of entry maneuvers 

3. Configure orbiter for subsonic flight 

4 . Perform atmospheric flight subsystems checkout 

1.16.1 

1.16.3 

1.16.4 
1.16.2 

Powered Flight 


A. 

Deploy and ignite turbofans 

1.16.6 


1. Descent to ABES deployment altitude and velocity 
2 • Deploy air breathing engines 

1.16.6.1 

1.16.6.2 





Table 3-1 . (Cont . ) 


FHASE 

3 . Verify deployment 

4 . Start ABES 

a. perform engine start checklist 

b. spin-up engines 

c . provide fuel 

d. ignite engines 

5. Perform post-engine start checklist 

B . Perform subsonic flight to approach terminal window 

1. Perform energy management maneuvers 

2 . Perform descent approach maneuvers 

a. perform landing checklist 

b. accomplish approach checklist 

c. obtain clearance for approach 

d. perform flight to initial approach fix (IAF) 

e. report position at IAF 

f. activate automatic landing system 

g. perform descent and intercept initial 
penetration course 

XI. Approach and Lane 

A. Perform final approach 

1. Establish landing configuration 

a. maintain approach air speed 

b. lower landing gear 

c. perform flight to FAF 

d. report position at FAF 

e. transition to final approach course 

f . maintain glide slope and approach course 

g. acquire visual references 

h. perform visual correction 

B. Establish landing velocity and attitude 

1. Assume manual control 

2. Align vehicle guidance approach with visual 
flight path 

3 . Verify landing checklist complete 

4 . Maintain descent rate 

5 . Perform flare 

6. Monitor automatic landing system performance 

C. Perform landing 

1 . Perform touchdown 

a. maintain runway alignment 


1.16.6.3 

1.16.6.4 

1.16.6.4.1 

1.16.6.4.2 

1.16.6.4.3 

1.16.6.4.4 

1.16.6.5 

1.16.7 

1.16.7.1 

1.16.7.2 

1.16.7.2.1 

1.16.7.2.2 

1.16.7.2.3 

1.16.7.2.4 

1.16.7.2.5 

1.16.7.2.6 

1.16.7.2.7 


1.17 

1.17.1 

1.17.1.1 

1.17.1.2 

1.17.1.3 

1.17.1.4 

1.17.1.5 

1.17.1.6 

1.17.1.7 

1.17.1.8 

1.17.2 

1.17.2.1 

1.17.2.2 

1.17.2.3 

1.17.2.4 

1.17.2.5 

1.17.2.6 

1.18 
1.18.1 
1.18.1.4 
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PHASE 

b. touchdown main landing wheels 

1.18.1.1 


c. perform decrab maneuvers 

1.18.1.2 


d. touchdown nose wheel 

1.18.1.3 


e. deactivate automatic landing system 

1.18.1.5 


2. Perform deceleration 

1.18.2 


a. deploy deceleration devices 

1.18.2.1 


b. apply brakes 

1.18.2.2 


c. maintain runway alignment 

1.18.2.3 


3. Perform rollout 

1.18.3 


a. secure deceleration devices 

1.18.3.1 


b. perform post-landing checklist 

1.18.3.2 


c. taxi vehicle to safing area 

1.18.3.4 


d. park vehicle 

1.18.3.5 


e. perform safing checklist 

1.18.3.6 


f. deactivate vehicle flight system 

1.18.3.7 

XII. 

Go-around 



A. Perform go-around 

1.19 


1. Deactivate automatic landing system 

1.19.1 


2. Provide increased thrust 

1.19.2 


a. Set throttle levers for takeoff thrust 

1.19.2.1 


3 . Establish missed approach attitude 

1.19.3 


a. rotate vehicle to maintain approach attitude 

1.19.3.1 


b. verify positive climb rate 

1.19.3.3 


4. Establish climb-out configuration 

1.19.4 


a. perform speed brake retraction 

1.19.4.1 


b. continue climb 

1.19.4.2 


5. Complete missed approach pattern 

1.19.5 


a. climb to missed approach altitude 

1.19.5.1 


b. follow missed approach flight path 

1.19.5.5 


c. perform missed approach checklist 

1.19.5.6 


d. perform transition from climb to level flight 1.19.5.3 


e. reduce engine thrust 

1.19.5.2 


f . perform turn maneuvers to approach path 

1.19.5.4 

XIII. 

Mission Abort 



A. Perform mission abort operations 

5.0 


1. Perform orbiter pad abort 

5.2 


a. egress orbiter crew and passengers 

5.2.2 


b. safe critical orbiter systems 

5.2.4 
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2 . Perform orbiter mated ascent abort 5 . 4 

a. perform solo orbiter ascent entry 5.4.1 

b. perform launch site orbiter landing 5.4.2 

c. perform down-range orbiter landing 5.4.3 

d. perform once-around orbiter landing 5.4.5 

e. perform orbiter mission 5.4.6 

f. establish orbiter mission status 5.4.7 

3 . Perform orbiter ascent abort 5.6 

a. establish orbiter ascent, failure 8 

performance capability 5.6.1 

b. perform down-range landing 8 recovery 5.6.3 

c. continue mission 5.6.4 

4 . Perform abort from orbit 5.7 

a. establish orbit parameters 5.7.1 

. b. determine landing site availability 8 return 

time 5.7.2 

5.. Perform orbiter landing abort 5.8 

a. establish reduced turbo-jet thrust 5.8.1 

b. perform emergency. landing procedures 5.8.2 

XIV. Ferry Mission . . 

A. Perform ferry mission • ■ ’ ' 6.0 

1. Perform post -flight safing and servicing - 6.1 

2 . Prepare for ferry operations 6.3 

3. Perform ferry flight 6.4 

XV . Turnaround 

A. Perform turnaround maintenance operations 3.0 

1. Perform post-landing safing and securing 3.1 

2 . Perform hangar operations 3.2 
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Table 3-2. Preliminary Allocation of 

Functions/Subf unctions to Crew 


Function 

No. 

Function/ Subfunction 

Crew 


1.1 

Perform mated ascent 



1.1.1 

Perform initial ascent maneuver 



1.1. 1.1 

Monitor liftoff. : 

CDR 


1.1. 1.5 

Monitor time from liftoff 

CDR 


1.1. 1.6 

Monitor BV engine performance 

PLT 


1.1. 1.7 

Monitor OV propellant pressures 

PLT 


1.1.2 

Perform roll maneuver - 



1.1. 2.1 

Monitor pitch and yaw null attitude 

CDR 


1. 1.2.2 

Monitor roll parameters (rate, error) 

CDR 


1.1.2. 6 

Monitor time from liftoff 

CDR 


1.1. 1.6 

Monitor BV engine performance 

PLT 


1.1. 1.7 

Monitor OV propellant pressures 

PLT 


l.l. 3 

Perform pitch maneuver • 



l.l. 3.1 

Monitor roll and yaw null attitude 

CDR 


1.1. 3-2 

Monitor pitch parameters (rate, error) 

CDR 


1.1. 3- 7 

Monitor time from liftoff 

CDR 


l.l. 1.6 

Monitor BV engine performance 

PLT 


1.1. 1.7 

Monitor OV propellant pressures 

PLT 


1.1.4 

Maintain ascent profile 



1. 1.4.1 

Monitor gravity turn profile 

CDR 


1. 1.4.2 

Monitor 3g axial acceleration limit 

PLT 


1.1.4. 3 

Monitor roll and yaw null attitude . 

. CDR 


1.2 

Perform booster/orbiter staging 



1.2.1 

Monitor booster propellant depletion 

PLT 


1.2.2 

Configure orbiter vehicle for staging 



1.2. 2.1 

Enable staging sequence 

CDR 


1.2. 2. 4 

Activate orbiter attitude control propulsion 
subsystem 

PLT 


1.2.3 

Perform separation 



1.2. 3.1 

Monitor orbiter thrust 

PLT 


1.2. 3.2 

Monitor orbiter attitude 

CDR 
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Function 

No. 

Function/ Sub Function 

Crew 

1.8 

Achieve initial earth orbit 


1.8.1 

Monitor ascent trajectory 

CDR 

1.8.3 

Monitor MPS cutoff 

PLT 

1-9 

Perform space station/base logistics support 


1 . 9.1 

Perform orbit and phase changes 


l. 9 - 1.1 

Coast to 50 x 100 nmi orbit apogee 


1.9. l.l.l 

Deactivate MPS 

PLT 

1.9. 1.1.2 

Configure for space flight 

CDR 

1.9. 1.1. 3 

Determine o/v attitude 

CDR 

1.9. 1.1 . 4 

Enable platform alignment 

PLT 

1 . 9 . l.l . 5 

Configure for Delta V • 

PLT 

1.9. 1.1. 6 

Enable Delta V 

CDR 

1.9. 1.2 

Circularize orbit 


1.9. 1.2. 1 

Monitor Delta V 

CDR 

1.9. 1.2. 2 

Monitor ACPS 

PLT 

1 . 9 . 1 - 2. 3 

Perform, post-burn reconfiguration 

PLT 

1. 9 . 1 . 2. 4 

Determine o/V attitude 

CDR 

1 . 9 - 1 . 2. 5 

Enable platform alignment 

PLT 

1.9. 1.2. 6 

Configure for Delta V 

. PLT ! 

1.9. 1.2. 7 

Enable Delta V 

CDR j 

1.9. 1.3 

Transfer to 1 st semi-elipse 

• ! 

1.9. 1.3.1 

Monitor Delta. V 

PLT j 

1.9. 1.3.2 

Monitor ACPS 

CDR 1 

1.9. 1.3 . 3 

Perform post -burn reconfiguration 

CDR j 

1.9.1. 3.4 

Determine O/V attitude 

PLT j 

1.9. 1.3 . 5 

Enable platform alignment 

CDR 

1 . 9 - 1 . 3. 6 

Configure for Delta V 

CDR 

1 . 9 . 1 - 3- 7 

Enable Delta V 

PLT 

1.9. 1.4 

Perform NCC maneuver 


1.9. 1.4.1 

Monitor Delta V 

CDR 

1.9. 1.4. 2 

Monitor ACPS 

PLT 

1.9. 1.4. 3 

Perform post-burn reconfiguration 

PLT 

1.9. 1.4 . 4 

Determine O/V attitude 

CDR 

1 . 9 . 1 . 4. 5 

Enable platform alignment 

PLT 
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Table 3-2 . ( Cont . ) 


Function 

No. 

Function/ Subfunction 

Crew 

1 . 9 . 1 . 4 . 6 

Configure for Delta V 

PLT 

1 . 9 , 1 . 4.7 

Ehable Delta V 

CDR 

1.9- 1.5 

Perform CDH Maneuver 


1.9. 1-5.1 

Monitor Delta V 

PLT 

1.9. 1.5.2 

Monitor A CPS 

CDR 

1.9. 1-5. 3 

Perform post-bum reconfiguration 

CDR 

1 . 9 . 1 . 5.4 

Determine 0/V attitude 

PLT 

1.9. 1.5. 5 

Enable platform alignment 

CDR 

1 . 9 . 1 - 5. 6 

Configure for Delta V 

CDR 

1.9. 1.5. 7 

Enable Delta V 

PLT 

1.9.2 

Rendezvous with space station 


1 . 9 . 2 . l 

Monitor Delta V 

CDR 

1 . 9 . 2. 2 

Configure for rendezvous 

PLT 

1.9. 2. 3 

Visually acquire space station 

PLT/ CDR 

1 . 9 . 2 . 4 

Enable rendezvous 

PLT 

1 . 9 . 2. 5 

Control (translate) vehicle, as required 

CDR 

1.9.3 

Dock 


1.9. 3-1 

Configure for docking 

PLT 

1.9. 3.2 

Control (translate) vehicle, as required 

PLT 

1.9. 3. 3 

Transfer control to docking station 

CDR 

1.9. 3-4 

Power down 0/V 

PLT 

1 . 9.6 

Undock 


1 . 9 . 6.1 

Power up o/V 

PLT 

1 . 9 . 6. 2 

Receive control from docking station 

CDR 

1.9.7 

Separate, from space station 


1. 9.7.1 

Control (translate) vehicle, as required 

CDR 

1 . 9 . 7-2 

Configure for stationkeeping 

PLT 

1 . 9.8 

Stationkeep 


1 . 9 . 8. 1 

Power down 0/V 

PLT 

1 . 9 . 8. 2 

Enable stationkeeping mode 

CDR 

1 . 9 . 8. 3 

Monitor system/subsystem status, periodically 

cdr/plt 

1 . 9 . 8 . 1 + 

Power up o/V 

PLT 

1 . 9 . 8. 5 

Configure for space flight 

CDR 

1.15 

Perform, deorbit maneuvers 


1.15.1 

Configure for deorbit 

PLT 
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Table 3 - 2 . ( Cont . ) 


r 

Function 

Mo. 

Function/ Subfunction 

Crew 

1 . 15.2 

Determine vehicle attitude 

CDR 

1 . 15.3 

Enable platform alignment 

PLT 

1 . 15.4 

Select landing site 

CDR 

1 . 15.5 

Configure for Delta V 

PLT 

1.15.6 

Enable Delta V 

CDR 

1 . 15.7 

Monitor Delta V 

CDR 

1.15.8 

Perform post -burn reconfiguration 

PLT 

1.16 

Perform, entry and descent maneuvers 


1.16.1 

Configure for entry 

PLT 

1.16.2 

Monitor trajectory 

CDR 

1.16.3 

Configure for atmospheric flight 

PLT 

1 . 16.4 

Monitor descent maneuvers 

CDR 

1. 16.6 

Deploy and ignit turbofans 

PLT 

1 . 16.7 

Monitor subsonic flight to approach terminal 
window 

CDR 

1.17 

Approa ch 


1.17.1 

Configure for landing 

PLT 

1.17.2 

Monitor approach 

CDR 

1.18 

Land 


1.18.1 

Monitor landing 

CDR 

1.18.2 

Initiate drag chute 

PLT 

1.18.3 

Initiate braking 

CDR 

1 . 18.4 

Taxi to terminal 

CDR 

1.18.5 

Deactivate critical o/V subsystems 

PLT 
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each: subsystem. In addition, detailed timelines were developed showing all 
control actions required during each mission phase, from which associated 
display requirements were derived. 

Primary sources of subsystem control and sensor data were (1) the Phase 
B computer-compiled signal lists, which describe each planned input and 
output signal interfacing between the primary subsystems and the DCM, (2) 
subsystem drawings showing controllable components, (3) Phase B reports 
describing the operation of each subsystem, and (4) discussions with Phase B 
contractor engineers responsible for design of each subsystem. Control and 
display data accumulated from these sources were refined to provide a 
listing, by subsystem, of necessary and sufficient control and display 
signals for crew monitoring and control of all subsystems during both 
nominal and non-nominal operations. In general, completely automated 
functions (i.e., those permitting no direct crew interaction) were omitted 
from the listings. 

The complete, listing is provided in Appendix B. Each item in the list 
is categorized according to whether it is a control or a display function and 
whether it would be necessary to crew operation during nominal missions or 
non-nominal situations. 

Detailed task timelines were developed for each mission phase showing 
each required crew action, the general sequence of actions and the approxi- 
mate time at which each action should be performed. In general, it was found 
that, with the exception of a few time-critical tasks Ce.g., initiation of 
Delta V) , the sequence of actions was more important that the time of per- 
formance . 

Figure 3-3 shows the task sequences, superimposed on the mission timelines. 
Position of each task on the timeline is approximate and sequence-dependent. 
Tasks were not divided between Commander and Pilot for this timeline, pro- 
viding sane indication of the relative loading during each mission phase for 
wrost-case, one-man crew operation. 

3.7 DISPLAY/CONTROL CHARACTERISTICS 

A preliminary control/display layout was selected for use in the develop- 
ment of format concepts and for the crew workload analysis. This baseline 
concept was 'intended to be modified as alternative logic concepts were evalu- 
ated. 

3.7.1 Preliminary Design 

The baseline layout, shown in Figure 3-4, is comprised of 5 CRT’s and 
3 keyboards. Each crew member is provided with a primary and a secondary 
CRT. The fifth CRT is shared between the two crewmen. Each crew member is 
also provided with a keyboard from which he can exercise control of the 
mission/ system/ subsystems through any of the displays. The third keyboard, 
located between the crew members , serves as backup in the event of a 
keyboard failure. 
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1.2 PERFORM ORB1TER/ BOOSTER STAGING 
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SELECT AV CALCULATION PROGRAM 
SELECT AUTO MANEUVER TO BURN ATTITUDE 
ATTITUDE CONTROL MODE TO 'MAX DB' 






SELECT ORBIT PARAMETER DETERMIN PROGRAM j REPf ' AT,:D PA® ORBIT 
UPDATE STATE VECTOR 

Figure 3-3. (Cont.) 



TRANSFER TO FIRST SIMI-ELUFSE 


o 


'D 

O 


b 


o 

o 


o 

if 


<i J 


•o 

o 



-e 


-g 


<3 


4 



-© 




CD O’ O H (N W 

H H N N N (N 



Um 

Uh 

o 


<c .J 

>x o 

8 e 

'£'§ 

CJ 


r. < 


s 


w 

Q 


O 

H 

^ Cm 
n Ui 
* O 
oj - 




■&■ to . 


§ 


s 


•3P 


W- 


> 

< 

1*2 

a 


' P '•> - , 

w „ • .pc • £ u 

<■-. o - • ,-h - c2 

05 ff 

p 

§ 

■$3 

§ 

s< 

;fe 

•— > 
& 

P 

H fe e 

g: 

ft 

d 

H 

M 

2 : 

3 

~2 

ux 

H 

fc~ 

c-j 

x ; 

OS 

$9 p 

P u -P 

fe.fc fe fe 1 


fe 

01 

H, 

CO 

CO 

< 

2u 

t/oco <;• 

cp^- .co CO . C/3 ,co . 

a. 

CO 


cv m .zr. a? .;/b b T. H .'' 04 '. cv, ij-. • "in' to •' 

*/ - ' -. . . «7i- ‘*>H •• rH ".; 1 i .H -.*-4 1 


3-30 •. 

".A.r, v 




*’ '.» I.-;:-' 


\ ' - r •' >. V Ft< : - 



1.9. 1.4 NCC MANEUVER 
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UPDATE STATE VECTOR 
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Figure 3-3. (Cont. 



1.9.2 RENDEZVOUS WITH SPACE STATION 
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TRANSLATION CONTROLLER 'ON' 



Dock with space station (1.9.3) 
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1.9.8 SEPARATI: AND STATIONKLiHP 
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CLOSE FCI REACTANT SUPPLY 

SELECT CPU 3 TO STANDBY Figure 3-.'. CCont.) 



1.9.8 SEPARATE AND STATIONKEEP 
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Figure 3-.>. (Cont . 



PERFORM DEOKR1T MANEUVERS 
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SELECT ENTRY CALCULATION PROGRAM 3j. SELECT AC BUS AC3 TO GEN 
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SET BOOST DUMPS (MAIN 6 AUX) TO 'AUTO' 
SELECT COLLISION AVOIDANCE LITE 'ON' 



Deploy and ignite turbofans (at 3SK) (!. 0 . 6 ) 


o 

o 


H 

5 

3 

u. 


o 

3 

3 

3 


o 

CT) 


-c • 
u — < 
rt 

o 

v- 

CL, CM 
C3 — « 

o o 


3 3 

o 

O T> 

•- 1 c 
c — * 
o .< 

•A 

JO — 
D C3 
V> C 






c 

o 

u 










LX 


IX 



3 

3 









3 


3 

X 

X 

3 

3 









Q 


a 


< 

a 

CO 









»— i 



S 

s 


< 









O 


o 

o 

o 

o 

3 









H 


H 

H 

H 

t- 






>- 


2 





N 

t — > 

/ — \ 

H 




O 

O 


LX 


fO 



CO 

•3- 

rr 





3 

3 


CX 





» 

- 

«» 

3 




CL- 

a. 


O 


CM 


r-4 

Cs| 

•— i 

•— « 





OJ 

3 






' ' 

V ‘ 

w 

' — ' 

CO 




o 

c 


o 








< 







F— 


3 


3 

a : 

DC 

3 

2 




O 

o 




LX 


LX 

3 

3 

3 

3 




H 

k- 


/— > 


> 


> 

> 

> 

> 







3 

CO 

2 

LX 

2 

LX 

3 


3 

o 








O 

3 

O 

3 

3 

3 


1- 


X, 


K) 


< 

CJ 












* 

•> 


*> 

O 

3 

o 

3 

3 

3 

3 

< 


o 


CM 


o 

*— t 


O 

l- 

O 

O 

O 

O 


o 

H 


' — 

v — ' 

H 

V—/ 


.3 


3 

CC 

3 

3 









, — , 

X 

< — ' 




H 

o 

3 

3 


f- 

H 

3 

LX 

K> 

2 


2 

2 

2 

2 

3 

< 



?: 

2 

CO 

LX 

*> 

O 

•> 

O 

O 

O 

O 



< 

o 

3 

3 

o 

O 

CM 

U 

r-+ 

u 

LJ 

u 

U 

2 

O 

u 



>■ 



' — * 


* — • 





O 

H 

to 

a. 

>* 



3 


H 


H 


H 


U 



cc 

o 

o 

F— 

— 

H 

LO 


LO 

to 

to 

to 


s: 

2 


3 

3 

3 

l/j 


3 

3 

3 

3 

3 

3 





c_ 

cx 

< 


< 

rv* 

< 

a 

BC 

3 

3 

to 

h 

H 

3 

3 

LX 


xc 


■— 

H 

“ 

3 

~ 

“ 

3 

3 

3 

< 

c 

£X 

L0 

2 

00 

h- 

00 


H 


P 

3 

< 

< 













— 



o 

3 

3 

X 


LX 

LX 

3 

3 

3 

3 

3 

P 



F- 

z 

2 

2 


2 

2 

2 

2 

2 

2 

2 



< 




•— < 

— 

•— • 







to 

O 

CO 

3 

o 

3 

t_p 

LX 

w 

3 

o 

LO 

a 

3 

O 

3 


< 

H 

/- 

2 

2 



2 

2 

2 

2 

2 

2 

2 

3 


3 

< 

Li- 

3 

LX 

— 

LX 

LX 

’►X 

3 

3 

3 

3 

< 

H 

h- 

F— 

H 

h- 

f- 


( — 

f- 


f- 


H 



3 

3 

3 

3 

LX 

UJ 





3 

3 

3 

3 

3 

LO 

to 

t/> 

to 

tO 

LO 

LO 

tO 

LO 

to 

LO 

to 

to 

to 

to 

r-H 

CM 

»0 


LO 

O 


00 

CT> 

o 

_; 

CM 

to 


U0 











•— < 






ro 

i 

ro 

<L) 

C. 

3 

M 

■H 

LX 


3 4o 



.IS APPROACH AND I, AND 



c* 


— 

— 






O 



oo 



-J 



— * 


" 

• 



«-* 


O 

O 

z 


w 


F- 

F— 

o 


c 


IU 

LU 



o 


-4 

—4 

o 

N 

■H 


< 

< 

f- 


U» 


U 

u 


— • 

CO 


GO 

CO 

co 


t- 




LU 

i-H 

<D 


s 

s: 

H 

/ 







a> 


H 

h 

-4 

— N 

o 


-4 

-3 


4-* 

o 


< 

< 

CD 

H 

"T3 




Z 




d£ 

a 


O 

E 


< 

< 

O 

m 

E 


o 

o 

z 

cm 

o 


< 

< 

< 




cc 

cs: 

-4 

o 






*-> 

a> 


F— 

H 

F— 


cx 


U4 

lu 

LU 

4-» 



C/5 

to 

CO 

CM 












*c 


tO 




CM 

• 


00 

05 

o 

t— < 

CO 

00 


«— 4 

(N 

w 


«“ 4 




x: 

•—4 

*— 1 




a 


v — ' 






z 

- o 
o - 

- ZD O 

O < H 

H - 

O ^ 

< O CJ 

-HO 


tj- iu 

m 

to o - 

— i u, 

CM u u. 

- o 

»-*« — 

o 

a: H O 

w H 

> / — > 

lu to 


z u. z 

O u- H 

u o < 


O CO co 

a; a. 

X ^ z 


4 & 

lu 

z 

f- 

H 

C. 

X 


< 

O' 

m 

t— 

2 

X 

LU 

z 

H 


o 

o 

a 

O 

LU 

LU 

LU 

C3 

LU 

< 

LU 

LU 

4-H 

2 

CO 


C£ 

z 

OL 

LU 

CO 

H 


1 - 


C/) 

LO 

LD 

LU 

V 


LU 

< 

3 

a. 

o 

O 

>- 

< 

H 

o 

O 

Z 

ZD 

o 


< 

•U 

F- 

CO 

z 

z 

C 5 


U 

z 

z 

LU 

LU 

CO 








-4 

L— 

LU 








{- 

t— 

u. 

F- 


Cl 

4— 

-4 

f- 




f- 


LU 



LU 

LU 

LU 


z 



LU 

LU 

LU 

LU 


co 

CO 

CO 

CO 

CO 

CO 

a. 


CO 

CO 

CO 

UJ 

CO 

CO 


J 

CM 

to 


to 

sO 

r-. 

CO 

Ch 

o 

—“4 

IM 

to 

: 



SET ENGINE DEPLOY (1,4) TO 'RETRACT' 



19 PERFORM GO-AROUND 



o 

o 

in 

m 

co 

o 


o 

o 

m 

m 

co 

o 


o 


ot> 

c 

• H 

-o 

§ 


o 

-o 

3 


cO 

^ -O 

o o 

.o to 
E to 


V. 

o 

in 



to 

o 

(N 

X 

to 

X -I 
Cl. ' 


CC 

UJ 

> 

UJ 


d - 
- UJ 
O' UJ 
UJ Q 

a: •— 

to 

< o 

w {_ 

CC /— \ 
UJ 
■ 3 S 
O 


fNI 


UJ 

O 


a: 

UJ r- 
> ^ 
UJ 

i-J CtL 


~J 

O 

cc 


UJ 


< 

z 


H 

UJ - 
_J X 
CO z 

g 5 

UJ 

o 2 

5 5 


< 

—3 

2 

X 

< 

•» 

o 

o 

o 

O 



2 

CC 

IX 

cc 


O 

UJ 

H 


h 

o 

e- 

10 

2 

H 

2 

CX 


*— » 

O 

to 

O 

f- 

UJ 

Q 

u 

X 

O 

2 

Q 



a; 


o 

O 

UJ 


£ 


u 

i. 


to 

to 



f- 

X 


X 

H 

f- 

H 

a; 

UJ 

cx 

to 


O 

X 

2 

“ 

X 

o 

<X 

H 

»— • 

p 

a 

*— > 

X 


O 





UJ 

Z 

UJ 

p 

U. 


2 

UJ 

2 



o 



*—« 

to 

o 

B 

O 

UJ 

tx 

UJ 

CC 

Z 

H 

2 

CC 


< 

UJ 

2 

UJ 

UJ 

< 

< 



H 

H 


UJ 

UJ 

CL. 

UJ 

UJ 

UJ 

to 

to 

o 

to 

to 

to 


fN 

rO 

** 

m 

n£> 



3-^2 























■1 


Each CRT provides a 6 x 8 inch usable display ; surface*; Two alpha^ 
numeric character sizes, 7/32 inch and 1/8 inch, were assumed for majoB 
titles and the remainder of the format, respectively.. A , basic format . 
skeleton, shown in Figure 3-5, was developed. This skeleton reserves .j. 
certain display surface areas for information common . to all formats *' ¥hese 
include GMT (or MET) and event time, format title and- Code number and i-i 
special quick-access codes for other frequently required fdrmats. Standard 
symbols and conventions were also developed and are shown in Table 3-3 1 : The 
primary objectives in developing these symbol conventions Were to use 
familiar component symbols, taken from standard usage, within the professional 
disciplines represented in each subsystem (e.g. , electrical, hydraulics j 
etc.) , and to use symbols which can readily display the states of the i . 
components they represent (e.g., on/off, open/closed j etc. ) . 

j. ■ . : X ! F 

The keyboard contains a set of 0 through 9 numeric keys, -with which 
the crew member will perform most of his control actions . Associated With 
the numeric keys is a limited number of special funfctiori keys .which were 
tentatively identified during preliminary format concept development* ..Five 
of the special function keys are labeled with Roman numerals and represent 
the five CRT displays which may be controlled from that keyboard. Theie 
keys are interlocked to prevent tying more than one display to a keyboard 
at a time. , t 

In addition to the standard ENTER and CLEAR keys j an AUTHORIZE ke^ was 
provided to permit the crew member to authorize the coniputei' to perform' a 
function it has recommended . For example , if a . Cautioii and ' Warning light 
is displayed for which a different display format would be appropriate »for 
operator evaluation of the trouble , the computer would recoimnend the format 
and the operator would need only to actuate the AWLlORiZE key to permit , a 
display format shift. . / ... 

Plus, minus, E, N, S, and W key functions are provided on two spedial 
function keys . These functions will be used to enter Special qualifier's 
with numeric data inputs, like latitude, longitude, giiiibal angles, etc A 
The display format will determine the meaning of' the key. '<■' • ■ .p • 

Two additional keys, INCREASE and DECREASE , are provided for cohtiiut 
ously variable functions like volume controls, flow rates j btc . To usd; 
these controls, the operator must first select and enter thb code of the 
function to be controlled, after which he can increase or decrease the /, 
parameter while watching the displayed quantitative Variation.. ■ I 

. . • i! 

: ■ : 4 . f! : 

3.7.2 Operating Procedure . T' y. 

For purposes of workload analysis, a pr el iminairy. operating procedure 
using the control/display concept was developed the Operatbr would usd;, , 
the keyboard /display subsystem in the following manner. Thd operator wbuld 
first select the display surface for which he desires keyboard control by . 
selecting the appropriate Roman-numeraled key. The • selected key would ■ . 
remain depressed throughout all subsequent, operations uilt'il deselected By 
selecting another display surface to indicate the active : keyboard -display 
interface (the active display also shows a symbol to indicate that it it . •. 
active) . To display a format on the selected display surface, the operator 
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Figure 3-5. Basic Format Skeleton 



Table 3-3 . Standard Character Conventions 


Function 


Symbol 


Function 


Symbol 


1. Pump On 

2 . Pump Off 

3 . Pump Unknown 

4. Solenoid Valve Open 

5. Solenoid Valve Closed 

6. Solenoid Valve Unknown 

7. Pressure Regulator 
Flowing 

8. Pressure Regulator 




! 9. 


Pressure Regulator 
Closed 

Pressure Regulator 
Unknown 

Fan On 


Fan Off 


Fan Unknown 


13. Elec Pwr Oont Open 

14. Elec Pwr Oont Closed 

15. Check Valve 

16. Heater 


<D- 


— D 


17. Vent 


18. Manually Controlled 
Element 

19. Switch Open 


20. Switch Closed 

21. Jet Engine 

22. Rocket Engine 


23. In-Tolerance, Out- 
of-Tolerance 
Quantities (Press- 
ure, Flow, etc. ) 




a 

Dd 


Abbreviations 


24. 

Open 

OP 

28. 

Down 

DN 

32. 

Quantity 

Q 

25. 

Close 

CL 

29- 

Pressure 

P 

33- 

Voltage 

V 

26. 

Automatic 

AUTO 

30. 

Flow 

F 

34. 

Amperes 

A 

27. 

Manual 

MAN 

1 — 1 
OO 

Temperature 

T 
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Table 3-3. (Cont.) 


CONVENTIONS 

35. Reserve one-digit numbers for special usage. 

36. Within a format, use two-digit numbers, the meanings of which are 
unique to that format only but, when used with other formats, may 
have other meanings. 

37 . Each format will be identified by a three-digit number which is 
reserved for that format only. 

38. When a control action is performed, the control code will appear in 
the data entry verification window of the CRT. After visual verifica- 
tion, selection of the ENTER key will cause the control action to occur 
and will brighten the action word and code number; the previously 
commanded action word and code number will be reset to normal 
brightness . 

39. Format trees will use the following diagrammatic convention: 

XXX 


XXX XXX 


XXX XXX 


XXX 


40. Alphanumeric characters will be used in two sizes: 7/32" and 1/8". 

This will provide two display densities when the characters are used 
as follows: 

20 Lines High x 40 Characters Long 

7/32" high x .132" wide character; 1/16" line space; .065 character 

space 

30 Lines High x 60 Characters Long 

1 / 8 " high x .089" wide character; 1/16" line space; .044 character 

space 


XXX 

J 


XXX 


XX 




would enter' a three-digit number representing that format, taken from an 
index or from a format reference or he would use one of the one-digit codes 
presented in the upper right comer of the display (Figure 3-5) . The selec- 
ted format would remain on the designated display until deliberately 
removed, regardless of subsequent keyboard-display linkage; however, a 
keyboard can control only through the format on the display it is linked to. 

To perform a control action within a specific format, assuming the 
correct keyboard-display linkage, the operator would observe the display, 
locate the correct control action, either on a checklist or within a sub- 
system diagram, and enter the two-digit code number shown on the display 
next to the component to be controlled. As the code digits are selected 
on the numeric keyboard, they appear in the verification area of the lower 
right corner of the display. After visual verification, the code would be 
entered into the computer by pressing the ENTER key. If visual verifica- 
tion indicates an entry error, the operator would clear the digits from the 
verification area with the CLEAR key. 

The crew member may, at his discretion, display GMT on one of his main 
displays and Mission Elapsed Time (MET) on the other by selecting the proper 
display surface and entering the code of the desired time mode. Event time 
will normally be displayed automatically below elapsed time, counting down 
to the next major event in the mission. The crewman may reset the event 
timer on any display and start it timing from zero time as a special event 
timer by using an appropriate code. This would not affect the event timers 
on any of the other displays . 

If a Caution and Warning or Abort signal is received at any point in 
the mission, the format title on each display will be replaced by either a 
CW or ABORT character word. This word will flash until acknowledged by one 
of the crewmen activating a CW panel switch or the Master Abort indicator. 

3.7.3 Dedicated Controls/Displays 

Although an objective of the study was to provide as complete a manage- 
ment capability through the CRT/keyboard concept as possible, it was recog- 
nized that there would be a need for some minimum number of dedicated 
controls and displays to satisfy startup, safety and operator flight control 
requirements. Therefore, each subsystem control/display requirements list 
was evaluated to identify functions requiring dedicated controls and 
displays based on the following criteria: 

1. Requires immediate time-critical crew activation and/or recognition 

2. Is necessary for in-flight startup from battery power only 

3. Is a basic design of the subsystem and forces dedicated controls/ 
displays 

4. A continuous manual control task is required. 

A complete list of dedicated controls and displays is given in Table 
3-4. The fact that these controls and displays are identified as dedicated 
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Table 3-4. (Cont.) 

DEDICATED CONTROLS/DISPLAYS 
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DEDICATED CONTROLS/DISPLAYS 
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DEDICATED CONTROLS/DISPLAYS 
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does not preclude redundant provisions in the formats for alternate use by 
the crew under certain conditions. Dedicated controls and displays are 
listed by subsystem. No effort was made to design control /display panels 
or to establish optimum locations for dedicated controls and displays since 
this was outside the scope of the analysis . 

3.7.4 Formats 

Utilizing the control/display requirements, the format conventions and 
symbols and the subsystem schematics, sample formats were developed for 
management of each of the subsystems and for monitoring and control of 
system and mission functions. The objectives were (1) to demonstrate the 
feasibility of incorporating all non-dedicated control and monitoring 
requirements into a limited number of format types, (2) to provide suffi- 
cient format samples to permit verification of their utility during normal 
mission operations and contingency situations, and (3) to provide a basis 
for estimating total program and computer storage requirements for complete 
mission operations. 

Approximately 100 individual formats, 70 of which' are shown in Appendix 
C, were developed, ranging from a complete set of formats for the propul- 
sion subsystem to single samples for other subsystems. - Complete indexes 
for all required formats within each subsystem and for normal operating . 
procedures during the entire mission were prepared as a basis for estimating 
total requirements. These are shown in Appendix C. 

Five separate types of formats were developed, each having different 
utilization and display characteristics. These types are briefly described 
below, with references to examples in Appendix C. 

Indexes - Primary access to individual formats by the crew will be by 
indexes (format trees) . It is anticipated that at startup the first format 
to be displayed will be the master index. Including the master index, no 
more than two indexes are required to locate any format in the repertoire. 
Indexes are characterized as fixed format displays (no variable data) , using 
alphanumerics and horizontal and vertical vector generation and referencing 
only 3-digit format selection control operations. Format 100 is the master 
index, and normal operational procedure checklists are indexed in Formats 
101, 102, and 103. 

Subsystem Management - Theoretically, complete control of the entire 
mission could be exercised using only the subsystem management formats (with 
the exception of dedicated controls and displays) , although these formats 
are designed primarily for contingency activities like override of auto- 
mated functions, reconfiguration of subsystems and in-flight procedural 
changes. Subsystem management formats are either schematic or tabular in 
form, reference 2-digit discrete control commands, enable keyboard data 
entry and display variable data. Tabular formats are, in general, entirely 
alphanumeric, with variable data displayed as digital numerics. Schematic 
formats contain both numeric and graphic variable data and a high degree of 
graphic symbology. Format 601 is a representative sample of tabular 
formats showing variable status data and Format 764 is representative of 
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tabular formats permitting data entry. Format 507 is illustrative of 
schematic formats with both graphic and digital variable data. 

Vehicle Management - Vehicle management formats are primarily graphic 
displays of vehicle and mission profile data, such as vehicle flight profile, 
flight director information and horizontal situation data. These formats 
are characterized by providing virtually no control capability, displaying 
largely variable data, and, unlike the other display formats, requiring 
symbol rotation capability in the display mechanization. It is anticipated 
that one or another of these formats will be displayed on each crew member's 
secondary CRT throughout most of the mission. Format 721 is representative 
of this type of display format. 

Operational Procedure Checklists - During the analysis, it became 
apparent that a ma^or factor in operator performance of the mission tasks, 
within the available time, would be the crew's ability to follow the sequences 
of tasks through each mission phase. Possible approaches, within the 
context of the control and display concept under evaluation, were narrowed 
to two alternatives. In one approach, the crew would be provided a carry- 
on-board checklist, similar to that used in the Apollo missions. The 
checklists would reference the appropriate subsystem format wherein the 
necessary control for performing each task would be found. This approach, 
while the least expensive from a computer/ storage standpoint, would be the 
most time-consuming for the operator, necessitating frequent display format 
switching operations. 

The second approach would program each checklist for display on the CRT 
and would incorporate, for each task listing, such information as the action 
to be performed, the present state of the control, the alternative control 
modes and their associated codes, and, where appropriate, quantitative data 
relating to the status of the subsystem under control. The task would be 
performed directly from the checklist without necessity for referring to 
the individual subsystem formats. This latter approach, illustrated in 
Format 131, Appendix C, would require considerably greater computer storage 
capacity but was adopted for this study because it minimizes crew performance 
time, reduces possibilities for operator error and simplifies the crew's 
task of keeping track of operating sequences. 

The checklists, which would each consist of from 6 to 30 task events, 
would be displayed two events at a time. The task event to be performed next 
would be displayed in the primary location just below the related quantita- 
tive data. The task event last performed would be displayed below the 
event to be performed next. As each task is performed, the task list would 
sequence down, permitting the operator to observe the effect of the last 
command. 

To assist the operator in pacing his task performance, each checklist 
would be assigned an arbitrary time-to-completion of 15 seconds per event. 

At the start of the checklist, a cumulative timer would credit the operator 
with time remaining if the event is completed in less than the allotted time 
and would charge him if more than the allotted time is used. Thus, the 
operator could determine whether he is falling behind the event schedule. 
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The cumulative timer would be reset at the beginning of each checklist. 

Three event -hold conditions are also provided on the checklist. A 
TIME HOLD would be displayed if the next event should not be performed until 
a specified time in the mission. For example, after initiating the platform 
alignment program during the IMU ALIGN checklist, the next scheduled event 
would be to evaluate platform gimbal angles and calculated corrections. A 
time hold would be displayed for the 10 -minute period required for platform 
alignment. Removal of the displayed TIME HOLD would inform the operator 
that platform alignment is complete and data are available for performing 
the next event. A SEQUENCE HOLD would be displayed if the next event should 
not be performed until the other crewman has performed a constraining event 
in his checklist. For example, the platform alignment program of the IMU 
ALIGN checklist should not be initiated until the orbit data has been veri- 
fied by the other crewman performing the DETERMINE ORBIT checklist. If the 
other crewman is falling behind his performance schedule, a SEQUENCE HOLD 
displayed on the IMU ALIGN checklist would warn the operator to wait until 
orbit data are available. A CW HOLD would be displayed if a CW condition 
has been detected but not yet acknowledged by the crew. Acknowledgment 
would remove the hold display. 

The above HOLD conditions may be programmed to prevent the operator from 
performing the next event or they may serve only as warnings, depending on 
the criticality of the hold situation. In general, the interlock would be 
preferable to prevent inadvertent program mixups. 

Mission Timelines - To aid the crew in overall mission management, par- 
ticularly in coordinating individual checklists within each mission phase, 
mission timeline formats were developed. These are illustrated by Format 
203, Appendix C. Each timeline represents a period between major mission 
events and includes from four to a dozen checklists of operator activities. 
Each timeline (mission phase) consists of a time scale representing the total 
time for that phase with time blocks for each checklist appearing at the 
scheduled intervals along the time scale. A pointer moves along the time 
scale at a real-time rate indicating the passage of mission time. As 
checklist events are completed by the operators, the appropriate checklist 
blocks would be shaded. By visually correlating the position of the shaded 
area on the checklist blocks with the time scale pointer, the operator 
could determine the completion and timing status of mission events and the 
future procedures to be performed during the mission phase. 

The timeline for each phase would be called up automatically at the 
conclusion of the last checklist for the preceding phase. In addition, the 
timeline for any phase could be called up by either operator for display on 
any CRT. Since the mission timeline would normally be displayed on the 
fifth (center) CRT, if any other CRT fails, the center CRT could be time- 
shared between the mission timeline and any other display format, including 
checklists, by using the single digit commands 8 (checklist) and 9 (prior) 
in the upper .right comer of every display format. 
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3.8 SELECTION OF MISSION fflASES FOR DETAILED ANALYSIS 


Based on the mission/task timelines shown in Figure 3-3, four mission 
phases were selected for detailed timeline analysis. The four selected 
phases were: Coast Into Orbit (1.9. 1.1), Deorbit (1.15), Powered Flight 

(1.16) and Approach and Land (1.17). These phases were selected as being 
most heavily task-loaded for the crew based on preliminary inspections of 
the tasks required for each mission phase. 

During the Coast Into Orbit phase, operator tasks involve shutting down 
and dumping residual fuel from the main propulsion system, spacecraft recon- 
figuration for space flight, determination of vehicle attitude, target state 
vectors and orbit, IMU alignment and configuration and calculation for Delta 
V. With the exception of shutting down and dumping residual fuel from the 
main propulsion system, all of these tasks are repeated during successive 
orbital changes prior to Rendezvous. 

During Deorbit, the crew must configure for retrofire, activate the 
ACPS, select a landing site, initiate and monitor retrofire Delta V, con- 
figure for reentry, deactivate the OMS, initiate reentry maneuvers and 
monitor reentry trajectory and attitude. 

During the Powered Flight phase, operator procedures include configur- 
ing for powered flight , deploying and starting ABES engines , and monitoring 
powered flight maneuvers. 

During Approach and landing, crew tasks involve configuration for 
approach and landing, monitoring approach and landing and configuration 
for shutdown . 

In selecting these mission phases for detailed analysis, both the 
number of tasks to be performed by the crew and the time available for 
their performance were used as selection criteria. 

3 . 9 WORKLOAD ANALYSIS 

A workload analysis was performed, for the four selected mission phases, 
to determine whether the use of the keyboard/ CRT approach would be likely to 
require more operating time than is available within each mission phase. 

Both nominal and non-nominal operating conditions were considered, and 
keyboard operating procedures requiring both minimal and maximal access 
times to subsystem controls were analyzed. The analysis and results are 
described below. 

3.9.1 Nominal 

Subsystem, vehicle and mission management tasks were detailed for each 
phase and allocated to either the Commander (CDR) or the Pilot (PLT). In 
general, tasks involving vehicle and mission control were allocated to the 
Commander and tasks involving subsystem management were assigned to the 
Pilot although this could not be adhered to constantly throughout the 
mission without a resultant disproportionate assignment of tasks to one crewman. 
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Time available for each phase was diagrammed on a timeline which per- 
mitted allotting task times in increments of 15 seconds. A 15-second minimum 
increment was selected to represent the amount of time required for a crewman 
to perform a typical task involving (1) reading from a checklist the task to 
be performed, (2) evaluating whether conditions are suitable for performing 
the task, (3) reading out the code number of the task to be entered on the 
keyboard, (4) setting in the code number on the keyboard, (5) verifying the 
correctness of the entry, (6) pushing the ENTER button, and (7) verifying 
that the task action resulted in the desired change. Although time estima- 
tion procedures indicate that the crewman could probably complete this type 
of task in less time, the selection of 15 seconds per task may be expected 
to result . in careful , unhurried performance with minimum error rates . If 
the time available is sufficient for completion of all tasks with this per- 
formance time allocation, it may be concluded that the operations involved 
are not time critical. 

Tasks were entered on the timeline at the appropriate time of occurrence, 
separately for each crewman, with appropriate delays for such activities 
as waiting for completion of alignment, evaluating status, etc. Results, 
shown on the timelines (Figures 3-6, 3-7, 3-8, and 3-9) indicate that at no 
point in the mission will the crewmen be overloaded nor will they be per- 
forming time-critical operations during a nominal mission. The evaluation 
is based on the assumption that each crew member will be operating primarily 
from a CRT-presented checklist, with occasional reference to other display 
formats for short term operations. The absence of time-critical tasks 
results from the basic Phase B design in which time-critical tasks are auto- 
mated in most cases by basic provisions built into each subsystem. 

It is evident from the timelines that considerable leeway exists for 
alternate approaches to using the CRT/keyboard control and display subsystem. 
The timeline assumes that each crewman operates from a CRT presented 
checklist appropriate to the mission segment , wherein alternative command 
actions and present status are provided as part of the checklist; references 
to other formats are infrequent and display switching is minimized. As an 
alternative, virtually all of the control actions assumed for the checklists 
can be made from subsystem and vehicle control formats, providing the 
crewman with greater overall visibility of configuration status, but requir- 
ing more display switching functions. Sufficient time is available 
throughout the mission phases for this latter approach also. For example, 
the largest number of subsystem reconfiguration tasks are required just 
after completion of the main engine bum following separation. On the 
timeline (Coast Into Orbit Phase) , these activities are assigned mostly to 
the Pilot, in keeping with the task assignment philosophy, while the 
Commander monitors trajectory and mission parameters. During the first 20 
minutes after engine shutdown, the Pilot would have available seven minutes 
of slack time. If the subsystem control tasks were performed from indi- 
vidual subsystem formats, rather than from a checklist display, the Pilot 
would be required to switch formats 12 times using three of the available 
seven minutes of slack time. No other series of tasks approaches that 
degree of format switching complexity. 
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Figure 3-7. Deorbit Workload Timeline (Cont.) 
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TIMELINE APPROACH AND LAND (1.17-1.18) 
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3.9.2 Non-nominal 


The evaluation of non-nominal operations involves similar assumptions, 
in that special checklists would be available for all abort and major 
malfunction situations. As with nominal operation, time-critical reconfig- 
uration requirements were automated by the basic Phase B design. Reconfig- 
uration requirements, such as isolating a leaking valve or turning off a 
mlfunctioning fuel cell, require location of the appropriate subsystem 
format for display and identification of the appropriate control input code. 
This should require no more than one to one and one-half minutes under 
present concepts . 

The failure modes which potentially have the greatest impact on system 
operation for the CRT/keyboard approach are those involving failure of the 
displays or keyboards themselves. The critical question i whether 
scheduled operations and monitoring can be performed with fewer than the j 
five CRT's and three keyboards assumed for the study. Therefore, failure 
modes involving loss of two of the five CRT's or two of the three keyboards 
were investigated . 

2 CRT Failure Mode - The loss of two CRT's, whatever the combination, 
would result in one operator having two CRT's and the other only one. The 
worst case, assumed for the investigation, would occur if one operator lost 
both of his primary CRT's, forcing him to rely on the shared CRT as his 
primary display . 

It was assumed that, during nominal operations, each crewman would use 
one of his primary CRT's for the display of the current checklist and the 
other primary display for major system or subsystem parameter displays, as 
required, to monitor mission progress and to verify the results of system 
operations. The fifth CRT could be used for format selection (usually 
unnecessary with the study concept) and for the display of supplementary 
information for either operator on a short-term basis, but normally would be 
used for mission timeline display. The loss of the two CRT's would restrict 
one operator to the display of either checklist or parametric data, but not 
both. Several alternatives are available for dealing with this situation. 

One alternative would involve reassignment of checklist tasks. This 
could be accomplished either by combining (interleaving) tasks by computer 
control or by special checklists, stored for just this type of contingency. 
In either case, tasks would be reallocated to permit the crew member with 
two displays to handle those tasks requiring simultaneous display- of two 
formats and the other crew member to perform routine control or monitoring 
tasks involving a single format or checklist display. From a time stand- 
point, the worst case would be to assign the crew member having two displays 
all checklist tasks. Referring to the Coast Into Orbit timeline, 118 tasks 
must be performed between the completion of main engine bum and the next 
phasing Delta bum. Using the unhurried task rate of 15 sec per task, these 
tasks could be completed in approximately 30 minutes; total time available 
is approximately 45 minutes. The timing of most tasks within a phase 
generally is not critical as long as the proper order of occurrence is 
maintained. Thus, it seems likely that one crewman could perform all or 
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most of the checklist tasks without strain. The same relationship between 
time required and time available holds also for the other three mission 
phases . 

A second alternative would be to require that the crewman having access 
to only one display time-share it between checklist display, system or 
parametric displays and the mission timeline. This would result in increased 
performance times due to the increased switching required. However, the 
need for other display access may be considered less critical under degraded 
conditions and some adjustment may be made in the checklist assignments of 
the two crewmen. 

2-Keyboard Failure Mode - The loss of two of the three keyboards would 
require that one crewman perform all of the control tasks, as well as the 
selection of display formats for both crewmen. The foregoing analysis of 
the feasibility of a single crewman performing all checklist tasks is 
equally applicable to the loss of two keyboards. Although a greater work- 
load for one crewman would result, the increase would be unlikely to 
overload him. 

3.9.3 Conclusion 

Based on the above analysis, it is concluded that the control/display 
concept under study is feasible from the standpoint of operator workload. 
During both nominal and non-nominal situations (other than those obviously 
requiring use of dedicated controls and displays) , the crew will not be 
forced into a work overload situation resulting from characteristics of the 
keyboard-CRT approach either in accessing information or exercising control 
over the system. 

3.10 TOTAL DISPLAY AND CONTROL REQUIREMENTS ESTIMATE 

The preceding analyses of information and control requirements , format 
development techniques and operating procedures provide the basis for esti- 
mating total control and display requirements for the Orbiter Vehicle 
(omitting remote station operations) . This estimate provided the basis for 
subsequent sizing and mechanization of preliminary design concepts developed 
and evaluated during later study phases. 

The total quantity and types of data and formats required are 
summarized in Table 3-5. Formats were divided into seven classes. Repre- 
sentative samples (shown by the numbers in parentheses after each format 
group title) were examined to determine the numbers of alphanumeric and 
symbolic characters required for display of static and dynamic information. 
These numbers were adjusted by a weighting factor which represents the per- 
centage of the sample format density judged to be found in the average 
format of that class. The adjusted character count per format, multiplied 
by the number of formats within the class, yields the total number of 
characters required for displaying that class of formats. 

In estimating character requirements, alphanumeric characters included 
letters , numbers , decimal points and percentage notations . All other 
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characters were counted as wymbols. A line segment was counted as a single 
symbol, regardless of its length, as long as it did not change direction or 
become interrupted . Characters were counted as dynamic if any change to 
the character could occur during system operation, such as a change in size, 
brightness, length or presence. Static characters are fixed in the format 
and never change. 

The total number of characters that must be stored and programmed for 
display is approximately 60 8K. This number should not be confused with the 
total number of computer words required for storage (described in a later 
section) since techniques for compaction during programming cause the latter 
requirement to be considerably lower. 

It should be noted that 3/4 of the character requirements result from 
the operational checklist formats. This indicates that a considerable 
reduction in display requirements could be achieved by the use of some 
other method for providing checklist information; e.g., carry-on-board 
printed books, etc. This saving must be balanced against the high degree 
of utility, procedural simplification and time saving which an integrated 
checklist would provide. For most system operations, the checklist formats 
appear to be far more valuable to the crew than the Subsystem Management 
formats, the next largest character requirement. 
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4.0 CONTROL LOGIC CONCEPTS 


4.1 OVERVIEW 

The purpose of this section is to describe the control logic concepts 
developed as a part of the CRT/keyboard control and display approach and to 
test the feasibility of these concepts analytically from the standpoint of 
the operation and mission requirements . The section will describe the over- 
all control logic tree which will permit operator access to any display format 
in the system, as well as additional features provided to facilitate access 
based on operator need. Display sequencing and control sequencing will be 
described in detail. A series of diagrams is provided to describe the step- 
by-step sequencing of each display surface and the associated control actions 
during each of the selected mission phases. Finally, a description of key- 
board switch functions required to permit implementation of the control logic 
concepts is provided. 

4.2 CONTROL LOGIC TREE 

Crew access to any mission procedure or system management format may be 
gained through a set of index formats, with access to the lowest format level 
available by reference to no more than two indexes: the Master Index, and one 
of the sub- indexes (categorized as Operational Procedures, Mission Timelines 
and System Management) . Additional features which minimize access time 
include references within each format page to adjoining formats (as in flow 
charts), references to related but not adjoining formats likely to be needed 
for fault isolation, and references to contingency formats for each checklist 
task. A quick access method is provided for frequent or critical access 
requirements . 

4.2.1 Access Tree 

Figure 4-1 illustrates the control logic tree for accessing individual 
formats. The Master Index, which can be called for display by entering the 
three digit number 100, provides the access codes for all sub- indexes. The 
sub -indexes provide access codes to all individual formats. To use the 
indexing system to call up for display the Deactivate MPS checklist, the 
operator would call the Orbit Index by entering the access code 102. The 
displayed Orbit Index lists the Deactivate MPS checklist under the Orbital 
Transfer mission phase. Entering its access code, 131, would cause the display 
of the first task of the Deactivate MPS checklist, together with its associated 
checklist data. 

If the operator wished to call up a subsystem diagram, starting from the 
Master Index, he would have followed the same procedure, illustrated in 
Figure 4-1. For example, to locate the liquid oxygen supply schematic for 
the Main Propulsion System, the operator would enter the Propulsion Index access 
code 500, then the MPS L02 Supply access code 504, shown on the Propulsion 
sub- index. Complete formats for all of the indexes are contained in the format 
layouts in Appendix C. 
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4.2.2 Intrafoimat Referencing 

Normally, it would be unnecessary, for the crew to use the indexing 
system to determine access codes for other formats, since advantage is taken 
of the interrelationships between foimats and the probable accessing require- 
ments of the crew during the design of the individual formats. Figure 4-2 
illustrates two provisions for direct access. All lines leading into and 
out of format schematics, such as the MPS L02 Supply shown in the figure, 
are labeled with their source or destination access codes. For example, 
the oxygen supply line goes to the MPS engines, diagrammed on format 507, 
as indicated by the arrowhead leading from the LOX tanks. In addition, 
analysis indicates the likelihood that during fault isolation the operator 
may need access to subsystem displays that do not directly interface a 
particular format. These access codes would be displayed at the bottom of 
the format, as, for example, the Gimbal Hydraulics format 431, shown at the 
bottom of Figure 4-2. 

4.2.3 Checklist Referencing 

During normal mission operations, the crew will be using mission procedures 
(checklists) in a predetermined sequence. With the exception of initial selec- 
tion, this will also be true of abort and emergency procedures. At the end of 
each checklist, the operator is required to select the next checklist to be 
performed. To avoid the necessity for returning to the index to determine its 
access code, the last task in each checklist is an instruction to the operator 
to call the next normally performed checklist and provides the access code 
for its retrieval. The operator, though normally expected to follow the pre- 
determined sequence, may disregard this instruction and call a checklist out 
of sequence, in the event that some contingency requires repetition of a 
previously performed procedure or because a change is required to the normal 
mission sequencing. In the latter case, if the access code for the out-of- 
sequence checklist is not listed under Contingency formats, the operator would 
be required to return to the index for the correct access code. 

The Contingency access codes listed with each task on the checklist 
format (see format 131, Appendix C) follow the same selection principle as 
access codes displayed on subsystem formats. They represent the three formats 
most likely to be selected by the operator if he feels the need for further 
information about subsystem status before performing the specified task. 

4.2.4 Task Referencing 

In addition to the checklist on his primary display, each crew member 
normally will need an additional monitor format on his secondary display. 

For example during ascent, following separation from the Booster Vehicle, the 
Commander will monitor the OV Ascent Monitor format (728, Appendix C) . Although 
such display formats could be accessed from the indexes, this would normally 
be unnecessary because, at the appropriate point in the checklist, a task 
would be inserted instructing the operator to call the recommended display on 
the other CRT, together with its access code. Again, the operator may choose 
to access the index to locate the access code for another format he prefers. 
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Figure 4-2 Subsystem format illustrating access codes for other related formats 
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Figure 4-3 Sample subsystem schematic format 
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Figure 4-4 Sample tabular control list format 
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Figure 4-5 Sample tabular status listing 







Figure 4-6 Sample data entry format 
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Figure 4-7 Sample vehicle management format 






subsystem status and configuration verification. Each subsystem format con- 
tains diagramatic representations of all components operable by the crewmembers 
as well as other important components necessary for understanding the working 
of the subsystem element. Refering to Figure 4-3, symbols may be seenrepre- 
senting valves (V) , pressure regulators (2) , check valves (3) , vents (4) , cabin 
outlets (D , and supply tanks (b)~ Each comp onent',~ 'for which - inf oimation^ is 
available from data management concerning its status, i.e., open/closed, on/off, 
etc., is shown symbolically in its sensed state. For example, valve @ is 
open, permitting oxygen flow through to the primary regulator, whereas valve ( 7 ) 
is closed, forcing N2 flow through the pressure regular ® in parallel with it. 
Components which do not show status, e.g., pressure regulator (T ) , do not have 
sensors associated with them, so that their status cannot be determined; usually 
they cannot be controlled by the crew. 

All components operable by the crew have indicators which tell the crew 
what the last commanded state of the component was . This is shown by a 
brightening of the command code (indicated on the drawing by heavier printing 
of the command code) associated with the component. For example, valve © 
(Figure 4-3) was last commanded open, as indicated by the heavily printed OP 01 
associated with it. In some cases, such as pressure regulator (8) , the component 
has three modes, one of which is automatic. As shown for (|) , the last commanded 
status was AUTO. By comparing the commanded state with the actual state, the 
operator may perform one type of manual fault isolation. In the case of pres- 
sure regulator (8 ) , the commanded state was AUTO and the system has set the 
regulator to ON. Whether that is the appropriate setting would depend upon 
the condition of the cabin atmosphere and the quantitative data also available 
on the format --a determination to be made by the crew. 

Certain of the controls were assumed, for purposes of the analysis, to 
be dedicated -- manually operable at a control external to the keyboard. An 
example, in Figure 4-3, is the Emergency 02 Low Pressure Regulator valve (9). 
Although the status of the valve is shown on the diagram, the operator must 
changie the status by adjusting the valve elsewhere in the cabin. 


In addition to component status, most subsystem schematic formats provide 
quantitative information concerning pressure, temperature, voltage, or other 
parameters relevant to subsystem status. Quantitative data are presented 
normally either in the form of graphic bar charts or as digital numbers . The 
choice of either type of display depends upon the degree of precision required 
by the crew when using the data. 

Bar charts may take either of two forms. The most commonly used type 
displays the measured parameter as a vertical bar scaled in relationship to 
upper and lower tolerance limit markers (e.g., @ , Fig. 4-3). Both the 
upper and lower limits, as well as bar height may vary as conditions change. 
When the parameter value falls above or below the tolerance limits, the 
digital value of the parameter appears flashing between the tolerance limit 
lines. The second type of bar chart represents the parameter value as a 
percentage of total value permissable. This is used most often for parameters 
like fuel quantity, where the bar height indicates the percentage remaining of 
total fuel capacity. Limit lines are usually unnecessary with this type of 
bar chart. 
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In using subsystem schematics as monitoring and fault isolation displays, 
the operator would be expected to scan each element of the subsystem for dis- 
crepant quantitative readouts (bar charts and/or digital values) . Discovery 
of a discrepancy would then require the use of standard troubleshooting logic 
to locate the responsible component and to formulate a workaround (e.g. by- 
pas siTtg~a _ valve— iso-la ting-a-fue-l— t-ank— ef-e-r-)- 


Tabular Control Formats 

Certain subsystems or subsystem elements do not need schematic diagrams 
or graphic displays to enable the crew to use them effectively. In those cases, 
commands and control status are presented in tabular lists, designed to permit 
ease of location of control elements . An example of this type of format is 
shown in Figure 4-4. Both exterior and interior lighting control status is 
shown by the relative brightness (two-state) of the individual commands asso- 
cizted with each lighting type and location. In the figure, all lighting 
controls are OFF. 

Tabular Status Formats 

A number of information parameters is needed by the crew to monitor 
system status, but they have no control functions associated with them. These 
parameters are found most often in system areas like configuration management, 
caution and warning and data management. Display of these parameters is most 
suitably presented in tabular formats, as in Figure 4-5. The format depicted 
lists all LRU's in the GN§C, the number of units on board, which of the 
units are in operation, which are available and which have failed. The 
operator would be able to determine when backup in any LRU category dwindled 
to a critical point. The WARNING in the last column of the figure indicates 
that only one Star Tracker Unit is left available because of the failure of 
Unit 2. 

Data Entry Formats 

i 

Occasions requiring the crew to enter numeric data into the computer 
are rare, associated primarily with contingency situations, such as changed 
rendezvous assignments or altered mission profiles. A special display format 
for entering data is shown in Figure 4-6. Procedures for data entry are 
described in the Control Sequencing section below. 

Vehicle Management Formats 

Display formats for monitoring and control of vehicle flight parameters 
are modeled after standard aircraft instrumentation and instrumentation 
developed during the Apollo program. A sample vehicle management display is 
shown in Figure 4-7. With this display, present pitch and yaw angles are 
read out on the simulated attitude ball under the fixed vehicle symbol. 

Roll angle is indicated by the pointer on the inside edge of the calibrated 
circle. Roll, pitch and yaw rates are indicated by moving pointers on fixed 
scales, as are the error magnitudes for each axis. Vehicle flight parameters, 
such as velocity, altitude, altitude rate, etc., are digitally displayed 
in the boxes under the ACTUAL heading, while error direction and gross magni- 
tude is indicated by moving pointers on the scales associated with each 
parameter. This display is used during ascent and includes a graph of the 
altitude versus velocity profile, with a "window" of the required H/V limits 
for desired orbit. 
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Permanent Format Data 

As illustrated on Figures 4-3 through 4-7, time data and quick access 
codes are displayed with all formats . On the top left comer of the format 
is displayed either Mission Elapsed Time (MET) or Greenwich Mean Time (GMT) , 
"^depending on operator selection! It - is~Tmti"cipated”th'at~each~crew _ member 
would select GMT on one of his two CRT's and MET on the other. Below the 
clock readout is an event timer. Normally, it is set to display time to the 
next major event, e.g., Delta V, etc. At the option of the operator it may 
be reprogrammed to operate as an elapsed-time event timer. Procedures for 
this option are described in the Control Sequencing section below. 

Quick access codes are displayed in the upper right comer of every format. 
INDEX Code 7 provides immediate access to the Master Index. CHKLST Code 8 
accesses the next task to be performed on the checklist scheduled for the 
operator position from which the display is commanded. PRIOR Code 9 accesses 
the last format displayed on the CRT from which the code was commanded. 

At the lower right margin of every format is a small box. This is the 
entry verification area reserved for display of the keyboards input characters 
prior to entry. By checking the characters in this box before pressing the 
ENTER key, the operator can verify that the numerics about to be entered are 
the same as those he intended to enter. 

4.3.2 Operating Procedure Checklists 

All operating procedures associated with normal operations, aborts and 
major emergency situations will be stored in the form of checklists for 
display and control by the crew using the keyboard/CRT control and display 
concept. Individual checklists will involve anywhere from four to thirty 
operator tasks. Checklists will be scheduled for each of the crew, as indi- 
cated by the C (Commander) or P (Pilot) after each checklist format number 
on the operating procedure indexes (101, 102, 103, 170, Appendix C) , but they 
may be called and performed by either crew member. In the event that one 
crew member is incapacitated, an emergency procedure would provide a combined 
checklist format operable by a single crew member. 

Figure 4-8 contains a sample checklist format. The following description 
of the information contained on the figure is representative of all checklists 
assumed for the study. 

The checklist is divided into two sections. The upper section is reserved 
for quantitative data associated with the task to be performed. In the event 
that no data are available or needed, the data space is left empty. 

The lower section of the checklist format contains two tasks, the task 
to be performed (directly under the task category headings) and the task 
last completed (below the task to be performed) . The task description con- 
sists of an action verb, displayed in 1/4" bright letters, and the object of 
the verb written in 1/8" lower intensity letters. In the illustration, the 
action verb is OPEN and the verb object is ENG 2 PREVALVE. The present status 
consists of an adjective describing the present condition of the verb object, 
written in 1/4” bright letters. The options available to the operator are 
divided into normal and contingency' alternatives. Normal options include all 
of the control actions associated with that task that the operator has available. 
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Figure 4-8 Sample Checklist Format 


In the illustration, both OPEN and CLOSE are available options, even though 
the valve is already closed. Contingency options normally include System 
Management format numbers directly related to the assigned task. 

Additional information associated with the description and options of 

the next task to be completed includes a cumulative" t'ime~ readout^o~as sis t- 

the operator in pacing his task activities. Each task is assigned a nominal 
15 second completion time. The cumulative timer credits the operator with 
positive (+) time if the task is completed in less than 15 seconds, negative 
(-) time if he takes longer than 15 seconds. 

Too much positive or negative cumulative time may result in the display 
of a SEQUENCE HOLD or TIME HOLD warning. These indicate to the operator 
that he must delay his next task to (1) allow the other crew member to catch 
up in task sequencing or (2) permit mission time to catch up to the schedule 
task time, respectively. 

4.3.3 Mission Timeline Data 

, Special mission timeline formats are provided for display on the shared 
CRT to facilitate coordination of individual checklists with mission time and 
to provide overall visibility of mission progress to the crew. An example 
is shown in Figure 4-9. Each timeline represents a subphase of the mission 
and is called for display automatically at the time designated as the scheduled 
start time of that phase. A pointer moves along the timeline scale at a real- 
time rate providing a reference index of the scheduled progress of the mission. 
Each checklist to be performed during that mission subphase is represented 
below the time scale by a rectangle whose length represents the scheduled 
completion time of the checklist and whose position under the scale represents 
the portion of the subphase in which the checklist should be completed. As 
each task of the checklist is completed, the rectangle is shaded by an amount 
proportional to the length of the rectangle and the total number of tasks in 
the checklist. By visually aligning the moving pointer with the shaded rec- 
tangles, the crew can determine the timelines with which the checklists are 
being completed. 

The timeline formats may be removed and/or replaced by other formats by 
a keyboard procedure described in the Control Sequencing section below. 

4.4 CONTROL SEQUENCING 

In accordance with the study objective, all control sequencing for the 
entire Space Shuttle orbital vehicle, with the exception of dedicated controls 
described in Appendix B, is performed using the 0-9 keyboard and a limited 
number of special function keys. To meet this objective, a special numeric 
code was developed, consisting of one-, two-, and three-digit numerals, which, 
when entered on the keyboard, command control activities that are unique 
either to the code or to the code in relation to the format on the active CRT. 
The following is a description of the utilization of this code and the special 
function keys, in terms of the various system control functions available to 
the operator. 
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Figure 4-9 Sample Mission Timeline Format 



4.4.1 CRT Control 


Any of the three keyboards can be used to exercise control over system 
elements through any of the five CRTs. Selection of the CRT which is actively- 
connected to each keyboard is made with special function keys labeled with 
roman“numerals— I— through-Vh — Each-GRT— : i-s-des-i-gna-t-ed-by-a-^ roman-numeral-, -with-- 1— 
at the left of the cockpit across to V at the right side. Thus, the Pilot 
utilizes CRTs I and II, the Commander utilizes CRTs IV and V and the two 
share CRT III. When a roman numeraled key on a keyboard is depressed, a 
control interface is established between the keyboard and the corresponding 
CRT.. As long as the key remains locked down the interface is retained. When 
a different roman numeraled key on the keyboard already interfacing with a CRT 
is depressed, the first interface is broken (the key is automatically released) 
and a new interface is established between the keyboard and the newly selected 
CRT. If a roman numeraled key on a keyboard is depressed, but represents a 
CRT already controlled by another keyboard, the requested interface is rejected 
(the key will not remain depressed) until the originally controlling keyboard 
relinquishes control of the CRT (the operator selects a different CRT for inter- 
face with the originally controlling keyboard) . 

4.4.2 Format Access Control 

All formats are called for CRT display by their three-digit code desig- 
nations. To call, for example, the Master Index for display on CRT II with 
the Pilot's keyboard, the special function key, II, is depressed, the code 
100 is entered on the keyboard, verified in the digital entry box in the . ; 
lower right copier of CRT II, and the ENTER key depressed. Subsequent format 
callups on CRT II may be made without re-depressing the special function key, II 
because the control relationship between the keyboard and the CRT remains in . 
effect until another CRT is selected from that keyboard. - 

4.4.3 System Control > •' . 

All system control commands are issued with two-digit codes, in conjunc- 
tion with a specific format. These commands may be issued as part of the 
individual checklist sequences or independently from System Management formats. 

System Management Control 

All control commands necessary to control the space shuttle vehicle through 
all mission phases may be made from System Management formats. However, the 
crew would require printed or optically displayed task lists referencing the 
correct formats to guide them through the task sequences. To avoid this 
necessity, normal control command sequencing was assumed to be performed from 
checklist formats. However, to control subsystem operation from System Manage- 
ment formats, the operator would use the following procedure. After calling 
to the display the format containing the components or functions to be con- 
trolled, the operator would determine the two-digit code representing the con- 
trol action desired, enter the numerals on the keyboard, verify the code entry 
in the verification box on the lower right edge of the format and press the 
ENTER key. 

As an example of this procedure, refer to Figure 4-3. Assume that format 
304 is displayed on the CRT which is active with the keyboard. To close the 
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Oxygen Supply valves (l) , the operator would enter 02 on the keyboard, verify 
the code in the verification box, and press the ENTER key. As a result, the 02 
command would be decoded in the display processor as a command to initiate the 
closing of the oxygen supply valves. This command, sent to the central processor, 
would cause the processor to send a signal to the valve solenoid, causing it 
'to close the ‘valve' At - the same - fhne~ the^ispTay'processor^wouTd~'change^the 
display symbology by reducing the intensity of the previous command to the 
valve (OP 01) and increasing the brightness of the present command (CL 02) . When 
the solenoid closes the valve, a signal is returned, via the central processor, 
to the display processor affirming that the valve is closed, causing the dis- 
play processor to change the open- valve symbol to a closed-valve symbol. The 
brightness and symbol changes are stored for future display update. 

Two types of system control actions require additional operations. One 
is the control of continuously variable components, like lighting. For these 
operations, the special function keys INC and DEC (increase and decrease, res- 
pectively) are used. Referring to Figure 4-4, incremental control of the 
interior flood lights may be achieved by first entering the control code for 
BRIGHT (example, 13 for the left interior flood) , then actuating the special 
function key INC or DEC, depending on the brightness level desired (determina- 
tion of the level achieved would result from observing the cabin floodlight 
being controlled) . Incremental control would continue to be available until 
either (1) the operator enters another control code from that same format, 
or (2) the operator calls another format to display on that CRT. 

The other type of system control requiring additional operations is data 
entry. Although rarely required, it is achieved through special format pro- 
visions. An example is shown in Figure 4-6. In the example, to enter new 
primary landing site latitude and longitude coordinates into the central 
processor (it is assumed the latitude and longitude coordinates are received 
from a ground station) , the operator would first enter the PRIMARY code 25, 
verify and press the ENTER key. This would cause the display of the LAT 
and LONG underlined blanks shown in the figure. The operator would then 
enter appropriate data, filling in the blanks from left to right, top to bottom. 

As the operator keys in the numbers, they are displayed in the blanks, where 
they remain for verification until the operator again keys ENTER. The lati- 
tude and longitude figures will then appear at the top of the format in the 
row labeled PRIMARY SITE in place of the previous primary site (FLORIDA) . 

Since no alpha- character input is available, the new site coordinates will not 
have a name label associated with them, unless this is a location previously 
stored in the computer. Similar procedures would be used for overriding 1st, 

2nd or 3rd alternate site coordinates. 

Two additional special function keys are used in conjunction with data 
entry: the one marked N+W and the one marked S-E. These keys are used to 
designate positive and negative numbers and to specify the earth hemisphere 
references for latitude and longitude. The identity of either key is deter- 
mined by the control command code preceding its use. For example, referring 
to Figure 4-6, in entering the latitude figures for the primary site override, 
described above, the control code 25 specifies that the next set of entries 
to follow will be latitude data. The first character of the latitude input 
is designation of north or south hemisphere; thus, keying the N+W key at that 
point will be sensed as N. The same logic applies to the interpretation of 
these keys in other data entry modes -- they are identified in terms of what 
is expected from the control command code preceding them. 
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Checklist Control 


All control command code operations are the same for checklist usage 
as for System Management format usage, described above. Referring to 
Figure 4-8, control commands available to the operator for each task are 

"shown unde^0PTI0NS^“N0RMAl7.~!n-tiie-example— the-oper-ato-r— s-nex-t-scheduled 

task is to open the Eng 2 prevalve -- the valve is shown to be presently 
closed. When the operator enters the control command code 03, verifies the 
entry and keys ENTER, several changes occur: (1) the checklist advances one 
step, i.e., in the example, task 2 replaces task 1 at the bottom of the 
checklist and, in turn, is replaced by task 3 in the middle of the format, 

(2) the Present Status of the component (Eng 2 Prevalve) changes (to OPEN) 
following receipt of confirmation from the data processor, (3) the large 
symbol size of the task just completed changes to small size symbols, while 
the new task is displayed with large symbols, where appropriate, and (4) 
control command code brightness shifts from CLOSE 04 to OPEN 03, to indicate 
the most recent commanded state. 

Certain task conditions may not require control command code inputs. 

If the task involves the manipulation of a dedicated control, no control 
command code is entered. Instead, the operator performs the task specified, 
using the dedicated control, then returns to the keyboard and keys ENTER. 

This advances the checklist one step, calling up the next task. If the 
task specifies putting a component into a state it is already in (e.g., 
opening a valve already open) , the operator verifies that no control command 
code input is required and keys ENTER, calling the next checklist step. 

If the operator wishes to sequence rapidly through a checklist in either 
direction, he may depress the special function keys INC or DEC to advance 
or return, respectively, at a rate of 2 steps/sec. Keying the single digit 
8 will return the checklist to the next task to be performed (see Quick 
Accessing, Section 4.2.5). 

Mission Timeline Control 

In the event that a crew member wants to use the shared CRT, which 
normally displays the mission timeline, to display another format, he may 
do so by selecting CRT III on one of the keyboards, usually the central one, 
then keying the desired format access code. To timeshare the central CRT 
between the mission timeline format and the newly called format, the operator 
may key the single digit 9 (and ENTER) repeatedly. Each time the number is 
entered, the preceding format will be recalled, permitting the operator to 
"flip" between them. This procedure would be most useful in the event of a 
failure to one of the CRTs, permitting operations to continue with the same 
display accessibility, but slightly degraded availability. 

4.5 CONTROL AND DISPLAY SEQUENCES 

A series of diagrams have been prepared, illustrating the sequences in 
which displays will be called and control actions performed, relative to 
each of the five CRTs in the Space Shuttle cockpit. These diagrams are of 
the four mission phases selected for detailed analysis; (1) Coast Into Orbit, 

(2) Perform Deorbit Maneuvers, (3) Powered Flight, and (4) Approach and Land. 
Figure 4-10 shows selected diagrams from the series. The complete series for 
the four mission phases is Appendix F. Each sequence is diagrammed in 15 second 
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time increments, equivalent to the arbitrary checklist performance times 
assumed for the workload analysis. 

The first task of the first series is the last task (at time 06:45) of 
the Achieve Initial Earth Orbit phase, in which each of the operators (Pilot = 

PLT. Commander = C DR) call new checklists for the be ginning of the_Coast_Lnto 

Orbit phase. The diagrams are read in the following manner: 

At time 06:45, the Pilot's CRT I is displaying the Monitor MPS checlist, 
his CRT II is displaying the Achieve Initial Earth Orbit format 726 or 727. 

The Commander's primary CRT IV is displaying the Monitor Trajectory checklist 
and his secondary CRT V is displaying the OV Ascent Monitor format 728. The 
shared CRT III is displaying the mission timeline for Achieve Initial Earth 
Orbit phase, indicating the end of the phase, with all of the checklist nearly 
complete. On PLT I, the checklist instructs the operator to "call Deactivate 
MPS checklist on display." The operator's action is to key I, 131 (with 
ENTER understood on all subsequent diagrams, unless no control code is 
required) . On CDR IV, the checklist instructs the operator to "call Activate 
ACPS checklist on display". The operator's action is to key IV, 130. 

Fifteen seconds later, at time 07:00, PLT I shows the first task of the 
Deactivate MPS checklist (set Eng 1 prevalve to open) and the required action 
(key 01). The operator's option codes are shown below the display diagram. 

CDR IV shows the first task of the Activate ACPS checklist (set space flight 
mode to ORB ATT) and the required action (key 02) . The mission timeline for 
the Coast Into Orbit phase is shown on COM III, indicating the timeline has 
just begun and showing the two checklists scheduled to be performed first. 

Subsequent steps in the sequence are interpreted in the same manner. 

Note that at time 19:-0, the Commander's checklist shows a 15 second TIME 
HOLD to allow time for the calculated and measured orbit data to be made 
available by the system. At 19:15, the Pilot's checklist shows a SEQ HOLD, 
to permit the Commander to complete the Determine Orbit checklist before the 
Pilot initiates the platform alignment program. Similar hold conditions are 
shown throughout the sequences, when appropriate. 

The control/display sequences diagrammed in Figure 4-10 indicate clearly 
the feasibility of controlling and monitoring system operations using the 
control and display concept under evaluation. At no point in the diagrammed 
phases are the two system operator's overloaded, or even hurried in performing 
scheduled tasks, and yet, all tasks are easily accomplished within the available 
mission time. 

4.6 KEYBOARD SWITCH FUNCTIONS 

The final keyboard design is shown in Figure 4-11. No additional functions 
were required beyond those originally assumed for the workload analysis. A 
description of the function of each key is provided below: 

1. 0-9 Numeric Keys. Provide the means for all format accessing and 
system control commands through numeric codes and for all data entry. 

2. I, II, III, IV, V Keys. Provide means for actively connecting the 
keyboard with one of the five CRTs similarly labeled. Keys are 
interlocked to prevent more than one CRT to be actively connected 
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FIGURE 4-10. CONTROL/DISPLAY SEQUENCES 
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FIGURE 4-10. CONTROL/DI SPIAY SEQUENCES (CONT.) 
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to a single keyboard at one time and to prevent another keyboard 
from assuming command of a CRT already controlled by a keyboard. 

3. INC Key. Provides means to control (increase) variable components, 
when used following specific control command codes. Otherwise, 
causes "scrolling" advance of checklist format at 2 steps/sec rate. 

4. DEC Key. Provides means to control (decrease) variable components, 
when used following specific control command codes. Otherwise, 
causes "scrolling" backwards stepping of checklist format at 2 
steps /sec rate.. 

5. AIJTH Key. Provides a means for the operator to authorize the sub- 
stitution of a display format recommended by the data processor as 
a result of an abort or emergency situation. 

6. N+W Key. Permits entering North, West, or positive designation 
during data entry, when used with special data entry formats. 

7. S-E Key. Permits entering South, East, or negative designation 
during data entry, when used with special data entry formats. 

8. ENTER Key. Used to signal display processor that preceding numerics 
have been verified and should be processed and transferred. When 
active CRT is displaying a checklist, ENTER command causes the check- 
list to advance one step, whether control command numerics preceded 
it or not. 

9. CLEAR Key. When entering numerics prior to keying the ENTER key, 
the CLEM key may be used to clear the contents of the entry veri- 
fication box in the lower right comer of the format. It may also 
be used to clear the entire data entry format prior to final entry. 
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5.0 PRELIMINARY DESIGN 


5.1 INTRODUCTION 

This section provides the technical descriptions of two alternate designs 
developed during the study, both considered feasible for implementing the con- 
trol/display concept described in the preceding sections. The primary differ- 
ence between the two alternates lies in the architecture of the display system 
itself. In one case. Concept A, the display system uses a relatively sophis- 
ticated random stroke technique. Concept B utilizes a dot matrix technique 
and is somewhat less complex. 

Before going into the details of the two concepts, a number of general 
considerations are reviewed below. The purpose of this review is to establish 
the various ground rules, constraints and driving functions assumed for the 
designs. 

5.1.1 General Considerations 

The display system alternate designs (A and B) are in conformance with 
the operational procedures described in Section 4.0, Control Logic Concepts. 
The designs were also shaped by the following assumptions derived from pre- 
vious studies. 

Guidelines 

Documented in the proposal and described in Section 3.0 of this report 
are a number of guidelines covering (1) human performance capabilities and 
limitations, (2) SSV program, mission and vehicle constraints, and, (3) con- 
trols and displays. All of those guidelines are applicable to these design 
alternates , but particular attention was given to those items listed under (3) . 

The controls and displays guidelines were, in general, results from 
previous studies and were in keeping with the state-of-the-art technology. 

Of the composite, those which explicitly affect either the design of the 
display system or establish the baseline configuration are restated below: 

(A) Five CRTs (selectable from any keyboard) 

(1) Usable Area: 6x8 inches 

(2) Writing Speed: 250,000 inches/second 

(3) Intensity Levels: 2 

(4) Character Sizes: 2 

(5) Spot Size: 10 mils 

(6) Position Accuracy: 1 part in 1,024 

(7) Refresh Rate: 50 times/second 
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(8) Flash Rate: 1 Hz 

(9) Contrast Ratio: 2.5/1 (8,000 foot lamberts) 

(B) Three Keyboards 

(1) Numeric and function keys only (no alpha) 

(2) No self-display capability 

(C) Update Rates 

(1) Dynamic: 20 times/second 

(2) Quasi-static: 1 time/second 

Other guidelines which affect the design implicitly will be mentioned 
throughout this section. Normally, that type of guideline affects the format 
structure, which in turn may affect the design of hardware or software or both, 
e.g., the capability to initiate a control sequence. This requirement is 
structured in the format but is actually executed through the organization 
of the software. 

DMS Configuration 

The Data Management System (CMS) selected for application of this concept 
was the North American Rockwell SSV Phase B configuration. The Phase B 
configuration is an integrated concept using a central processor inter- 
connected to all of the various subsystems via a data bus. In this manner, all 
subsystems are under control of the central processor: a Data Management System. 

For purposes of integrating the display and control subsystem into the DMS, only 
the central processor, the data bus subsystem, the mass memory and the DMS soft- 
ware organization are of concern. Given that the display and control subsystem 
will consist of five CRTs, three keyboards and the electronics to process and 
control the displays, the baseline configuration, including the DMS interface, 
is depicted in Figure 5-1. The Acquisition, Control and Test (ACT) units, as 
shown, are assumed to be part of the data bus subsystem. 

The two major driving functions produced by the DMS are the information 
transfer rates between the central processor and the display interface and 
the temporary storage capacity provided by the ACT units. These characteris- 
tics were determined from Phase B studies to be as follows: 

(A) Information Transfer Rate 

(1) Input: 25 times/second 

(2) Output: 25 times/second 

(B) ACT Storage Capacity 

(1) Input 124 32-bit data words 

(2) Output: 31 32-bit data words 
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(C) Maximum Information Rate 

(1) Input: 3100 32-bit data words/second 

(2) Output: 775 32-bit data words/second 

Control Logic Concepts 

The Control Logic concepts described in Section 4.0 provide much of 
the man-machine communications and as such establish many of the software dis- 
play requirements. A typical example would be the relationship of keyboard 
inputs to the expected system responses. This is primarily a software driving 
function and thus provides the basis for the structure of the keyboard program 
module. Additionally, these requirements define many of the one- and two-digit 
routines, some of which are common to all of the formats (e.g., the header), 
and many of which are unique to a given format. 

Display Formats 

The display formats (Appendix C) impose the greatest number of driving 
functions upon the design of the display system and the organization of the 
display software. This results from the variety of operational procedures 
performed by the crew by viewing formats and initiating simplified keyboard 
commands. The procedures are discussed in detail in Section 4.0. 

The driving functions resulting from format designs are discussed below 
in terms of their implications for design of the control and display system. 

Complexity 

The term "complexity" pertains to the variety of data contained in the 
many formats and the manner in which the data must be displayed. The basic 
format scheme requires that the data be displayed in all or any combination of: 

(A) Alphanumerics and special characters 

(B) Vectors 

(C) Graphics 

(D) Conics 

The design obviously must include the appropriate function generators. 

Additional complexities include the requirement to rotate a portion of 
the format about a given point (e.g., Format #721), which calls for the 
generation of the sine/cosine functions and multiplication to resolve the 
X, Y deflection voltages, together with holding registers for the initial po- 
sitioning, since only a portion of the display is rotated. Also, the require- 
ment to scroll the checklists (e.g., the 100 series formats) imposes special 
requirements on the organization of the software. There are several special 
requirements of this nature which are mentioned in the section on software. 
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Dynamic Data 

The term "dynamic data" involves those data which are variable with time 
and are required for display. The data can include either analog or discrete 
information or both. The point of concern here is the update rates required 
for this type of data. For this study, two rates were selected: 

Rate (1) : 20 times/second 

Rate (2) : 1 time/second 

Briefly what this information implies is that the routines operating 
on these data must operate at the frequency of the update rate and that the 
information transfer rates must be compatible. Furthermore, the dynamic data 
must be organized within the refresh buffers in such a manner as not to dis- 
turb the refresh cycle during updates. 

Man-Machine Communications 

This paragraph is intended to point out that the various keyboard inputs 
by the crew impact the software design. For example, a three digit input 
(followed by the "ENTER" key) is a format request, a two digit input is a 
system command, and a one digit input is a rapid access request. In essence, 
the driving function is the man-machine interface, i.e., the response of the 
system to the crew's input (see Section 4.0). 

Histroical Content 

The term "historical content" refers to the state or condition of the 
variables last commanded by the crew. This is best illustrated by the 
following example: 

Given a two-state variable (e.g., valve) the formats are designed to 
provide the following information: 

(A) The state of the valve as measured by the system 

ON: -©- 

OFF: -<D- 

(B) The last commanded state of the valve 

(This condition is displayed by setting either the 

"ON" or "OFF" to a higher level of brilliance respectively) . 

The actual state of the variable can be instrumented by simply sampling the 
variable. The last command which is analogous to a switch position must have 
been recorded previously. This could be done in at least one of two ways: 

(A) Writing the format back into mass memory 

(B) Storing the information locally in some sort of matrix 
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For this study the matrix method was selected for two basic reasons: 

(A) Writing back into mass memory increases data bus rates and is 
subject to error 

(B) The formats, because of control sequences, are so organized 

as to produce certain redundancies for many variables. Conse- 
quently, for each input command, more than one format may be 
involved, thus causing chaos on the data bus in attempting to 
update the various formats, if the format were to be rewritten 
into mass memory. 

Quantity 

Quantity as a driving function affects local memory size and software 
only to the extent of having to keep track of more of the same things. This 
is not a significant problem in the design. The greatest impact due to 
quantity (number of formats) is the mass memory (e.g., 400 formats at 400 words 
per format would imply 160,000 words of storage required). The actual estimate 
is provided in later paragraphs on memory storage estimates. 

Fault Tolerance 

The reliability requirement for the Space Shuttle has been given as fail 
operational -fail safe. This is an obvious hardware driving function, since 
a minimum of three elements are normally required to meet this constraint. 

Those requirements which are not so obvious include the means for detecting 
and isolating faults to insure failing operational or safe. Certain techniques 
are discussed further in this section. 

For purposes of this study, control/display system fail safe is defined 
as three displays and one keyboard operational. 

5.1.2 Design Objectives 

The primary goal of this study was to determine the feasibility of the 
concept identified for study. To achieve this goal, the following design 
objectives were adhered to during the course of the study. 

Hardware 

State-of-the-art technology was applied to arrive at a baseline system. 
Through a process of iterations, the baseline system was subjected to the 
various driving functions and optimized within the time available. To provide 
a level of confidence and a point for trade, an alternate scheme was designed. 

Software 

A working program structure was organized to a level sufficient to demon- 
strate feasibility and to aid in estimating the computer size, including local 
and central processing. In addition, a cross section of formats was programmed, 
based on the display control word structure, from which the mass memory was 
estimated. Coding of a typical format is given in Appendix D. 
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Man-Machine Communications 

. Provisions for a highly flexible operator-oriented system were made 
to allow crew participation in the overall system procedures. 

5.1.3 Mechanization Trade-Offs 

A number of mechanization trade-offs were conducted in the process of 
establishing the preliminary design. In most cases, because of the time 
limit, the trade-offs were based on results gained from similar studies 
and/or actual experience. In certain cases, however, a survey and/or 
detailed analyses was performed in support of the trade-off. 

Central vs. Local Processing 

There are two basic approaches to implementing the displays and controls 
in the shuttle. The first utilizes the central computer to call and control 
the formats and provide the display system with the selected format structure 
and all of the required supporting data. This approach is not suitable for 
the concept being studied due to the excessive requirements on the data bus 
and the degree of involvement needed for handling up to five active CRTs. 

The. second, more suitable, approach is that of utilizing local processing 
with smaller computers assigned to control the displays. These processors 
communicate with the central computer for system information and receive 
general format structures from mass memory. The number and size of the local 
processors needed is dependent upon reliability dictates and processing loads, 
respectively . 

The second approach was selected for implementing the preliminary design. 
Dedicated vs. Integrated Display System 

The reliability dictate (fail-op, fail-safe) requires that a minimum of 
three local processors be used in the design. Immediately the question arises, 
"Can a savings be achieved through integration?". An integrated display system 
was considered and a baseline was designed (Figure 5-2). In this particular 
design, the refresh memory storage buffers were the logical elements for inte-. 
gration. Rather than three independent (dedicated) buffer groupings, one re- 
grouping of five (one per CRT) with two spares was provided, wherein either 
spare could replace any one of the operating five. 

The problem with this organization is the existence of too many indepen- 
dent elements and thereby a complex multipath system. Whenever this occurs, 
an excessive amount of monitoring and switching is required which reduces the 
desired gain. A second problem with this particular mechanization, and one 
which leads to the selection of Concept A, is the speed requirement; i.e., 
operation of five independent CRTs using one refresh controller is very 
marginal. Updating five memory refresh buffers through the use of a single 
processor is very marginal, which leads to a need to divide the work load 
between the various elements. In so doing, the system begins to take the form 
of a dedicated system, i.e., Concept A, which is described later in this section 
and which is selected over that of the integrated design. 
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Stroke vs. Dot Matrix 

There are many pros and cons throughout industry concerning the use of 
stroke over the dot matrix technique and vice-versa. 

In the past, the random stroke method has been recommended because of 
its performance and versatility. The dot matrix (and raster) has been recom- 
mended because of its lav cost and reduced power. Recent advances in writing 
technology indicate that there is no reason for poor quality writing, whether 
the random stroke or the dot matrix technique is used. The trade-offs thus 
become versatility, cost, and power. Other trade-offs of concern include 
reliability and simplicity, which normally go hand-in-hand with cost and 
power, and software (complexity and magnitude) . 

To perform all these trade-offs and select an optimum system is beyond 
the scope of this study. Of concern here is the feasibility of design, 
using either the random stroke or dot matrix techniques. However, to develop 
a confidence level in the overall concept, both techniques were designed to 
the level of determining feasibility and are discussed in the following 
sections. 

5.2 CONCEPT A 

Concept A is one of two preliminary designs considered feasible for 
application of the control and display concept evaluated under this study. 

The design, including both the hardware and software, is in conformance with 
the operational procedures described in Section 4.0 and the general consider- 
ations outlined in this section. 

The basic design for Concept A is a dedicated system using local proces- 
sing and a random stroke writing technology. The reliability requirement has 
been given as fall -operational fail-safe. The final state, fail-safe, is 
defined as three displays and one keyboard operational. This, together with 
physical location considerations and crew requirements, determines the need 
for the three keyboards and five displays described earlier. Any keyboard 
must be able to select any one of the five displays. 

Concept A uses a basic 32-bit word structure over that of a 16-bit word 
for display and control for the following reasons: 

A. The selected IMS, including the computing subsystem, data bus, and 
mass memory uses the 32-bit word structure; therefore matching the 
word structure will contribute to interface ease. 

B. The technique used in this design is the random stroke method and 
requires a 10-bit resolution -- beam positioning can be achieved 
with only one word, thereby saving time. 

C. Control can be accomplished simultaneously with data words. 

D. Each processor must be capable of handling three CRT displays 
simultaneously; 32-bit words provide the required added speed 
efficiency using less hardware. 
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To meet the failure dictate, a minimum of three local processors is 
required. A further requirement for an overlap of one of the five displays 
to be controlled by two operating processors leads to the processor-display 
assignment provided in the following table 5-A. 


Display 

Processor 

Displays 

I 

II 

III 

IV 

V 

1 

X 

X 

X 

X 

X 

2 



X 

X 

X 

3a* 

V 

A 

X 

X 



3b* 



X 

X 



X 


*Either or 

Table 5-A. Processor-Display Assignment 

As a result of the design and analysis described below, it was concluded 
that configuration of Concept A diagrammed in Figure 5-3 is sound and meets 
the requirements. 

5.2.1 Concept A Summary Description 

A summary of the overall display characteristics is given in Table 5-1. 

The characteristics of the elements within the display system are provided 
in the following paragraphs. 

Operation of the display system involves keyboard selection, which assigns 
a display to a particular local processor. That processor receives further 
information from the keyboard relating to a format call-up (3-digit request) . 
The processor requests information to be sent from the mass memory, under con- 
trol of the central processors, to both the central and the local processors. 
The information received by the central processors includes, as required, by 
each of the formats: 

(A) Instructions for compacting measurement data 

(B) Measurement data addresses for display updating 

(C) Addresses for execution of certain 2-digit keyboard input commands. 
The information received by the local processor includes: 

(A) The display control words (format) 

(B) Special 2-digit keyboard input interpreting routines, e.g., a 
routine for interpreting the difference between a normal 

2 -digit command and one followed by data. 

(C) Special control words used for queuing the central processor in 
response to certain 2-digit input commands. 
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Type 

Area 

.Resolution 

Method 
Refresh Rate 
Update 
Characters - 

Character size 
and density 

CRT Writing Speed 
Intensity 

Display Control 
^display maximum : 


TABLE 5-1 - DISPLAY CHARACTERISTICS 


- Cathode Ray Tube - magnetic 5 electrostatic deflection 
-6x8 inches 

- .010 inches spot size with 10 bit digital to analog 
positioning accuracy 

- Stroke 


50 times /second 

24 times/second (dynamic), 1 time/second (quasi -static) 


Space (inches) 
Line Character 


36 alphanumeric 

27 special symbols 

1 space width 

Size (inches) 
h x 1 

1/8 x .089 
7/32 x .132 


Density* (Char.) 
HxL 

20 x 40 
30 x 60 


1/16 .044 

1/16 .065 

for caution and 


250,000 inches/second 

Two intensity levels; blinking at 1Hz 
warning 

3 32-bit words, 7 modes of operation 


1/3 maximum density or 600 characters /display 
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Upon receipt of the above data the local processor requests and receives 
one update from the central processor. The local processor updates the 
dynamic memory bank and then commands the refresh controller to initiate 
reading the dedicated memory refresh buffers . The controller reads from 
memory, via a direct memory access channel, the interface logic defined by 
three control words, as shown in Table 5-2. The control words are stored in 
correct sequential fashion in the refresh memory banks and timed to provide 
a refresh every 20 milliseconds . 

There are three sets of two refresh memory banks. The two banks are 
defined as static and dynamic. The static bank is reserved for non-varient 
control words, while the dynamic bank is reserved for those words requiring 
update information. In this manner the display processor can update the 
dynamic bank while the static bank is being read by the controller. 

The basic control word, as noted in Table 5-2, provides ten bits of 
X and Y coordinate data or sine and cosine of the angle of rotation. Three 
bits are used to identify which of the following modes is commanded: 


(A) 

Rotate 

(B) 

Symbol 

(C) 

Vector 

(D) 

Circle 

(E) 

Rectangle 

(F) 

Vector Perturbation 

(G) 

Spare 


Four sizes of circles and rectangles are possible. The vector perturbation 
mode permits incrementing the X or Y positions, selected with the axis incre- 
ment select bit, by the amount for the count indicated in the Data Word 1. 

A vector with a length equal to the other axis increment is written at each 
position. 

The word type is identified by two bits in each control word. The other 
bits are used as follows. A bit permits definition of one of two intensity 
levels. The blank bit controls the video on the Z-axis of the CRT. The 
flash bit enables the blinking of the beam at a 1HZ rate as required for the 
caution and warning function. The dash bit permits the writing of broken 
line segments for vectors. A vector is expressed by the starting and final 
points given in the basic and Data Word 1, respectively. A bit is available 
for parity error checking. 

The start-new- line bit permits the continuation of character writing in 
a page format by starting a new line at the initial x position with y decre- 
mented. As noted, Control Word 2 defines four characters which are written 
sequentially in text format. Table 5-3 indicates the 63 characters selected 
for writing. 

Each local processor can control up to three displays. The maximum refresh 
frame time per display is based on a mix consisting of 600 symbols and 200 one 
inch vectors. 

With the estimate of one inch per character, a display requires 800 inches 
of beam positioning for character writing. Since there are 30 lines and each 
is 8 inches in length, another 240 inches are estimated for positioning. 
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TABLE 5- 2 - DISPLAY CONTROL WORDS 


Bit 

Positions 


Command Words 


Basic 


Data-1 


Data-2 


0 

1 

2 

3 

k 

5 

6 

7 

8 

9 

10 

11 

12 

13 

lU 

15 

16 

17 

18 

19 

20 
21 
22 
23 
2h 

25 

26 

27 

28 

29 

30 

31 


Parity 

A 


X-Coordinate 

or 

sinQ 


y 


Y-Coordinate 

or 

cosO 


y 

A x or AY 

T 

Mode 

i' 

Spare 

Blank 

Intensity 

Size 

Size 

Word Type 
Word Type 


Parity 

A 


X. -Coordinate 
i 

or 

AX 


Y^-Coordinate 

or 

AY 


V 

A 


Count 

V 

Dash 

Blank 

Intensity 

Size 

Size 

Word Type 
Word Type 


Parity 

* 


Synbol-1 


V 

A 


Symbol-2 


V 

A 


Symbol-3 


y 


Symbol-1* 


y 

New Line 
Flash 
Intensity 
Size 

Si ze 

Word Type 
Word Type 
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Further, the electronics requires time to settle from each step position 
command. This is estimated to be 2 microseconds per character or 1.6 
milliseconds for the entire display. Using a conservative write rate of 
250,000 inches per second, the time for character formation and positioning 
is approximately 4 milliseconds. Note that blanked positions normally are 
twice the unblanked rate. The total time is 5.6 milliseconds (1.6 + 4.0) 
per display. 

Since three displays are to be controlled by one set of generators, the 
total time is 16.8 milliseconds. This value is within the 20 milliseconds 
required for a 50 times per second refresh. 

The interface between the controller and processor is closed loop, using 
an interrupt scheme. Upon completion of each CRT frame (end-of -message) , an 
interrupt is generated by the controller and issued to the processor. In 
this manner, the processor schedules the controller and updates the dynamic 
memories synchronously. The estimated time for servicing the interrups is 
approximately two percent of the duty cycle. This was computed based upon 
the processor having a 2.5 psec equivalent add time (short operation). 

Stroke generators were selected for Concept A. Analog signals are 
generated for the X and Y deflection voltages to produce line segments 
or strokes. Provisions have been incorporated for selective blanking of 
character (s) in local memory without affecting the remainder of the display. 

The CRT beam is deflected by currents through the deflection yoke. 

(The display control words required for each mode type are discussed in 
Section 5.2.1). Utilization of function generators preserves time and 
reduces memory and, and in general, the amount of electronics required. 

5.2.2 Display Elements 

The display subsystem consists of the following major elements: 

(A) Display Processors (3) 

(B) Display Controller Electronics (3) 

(C) CRT Displays (5) 

(D) Keyboards (3) 

The elements are interconnected so that no single failure is cause for 
a complete subsystem failure, Figure 5-4. The subsystem is designed for both 
automatic and manual reconfiguration. Automatic reconfiguration is under 
control of the central processor while manual reconfiguration can be initiated 
by the crew. 

Display Processors 

The general processor characteristics are listed in Table 5-4. The 
purpose of the display processor is to interpret keyboard inputs, convey the 
crew's commands, retain historical events, and display the desired data. In 
performing these functions, the processor is required to scale and convert 
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TABLE 5-4. 


BASIC PROCESSOR CHARACTERISTICS 


Type: 

Number System: 
Memory Speed: 
Memory Capacity 
CPU Registers: 


Interrupts : 


Typical Execution 
Times: 


Input/Output : 


I/O Rates : 
Technology: 


Digital, general purpose, stored program 

Binary, Fixed point, 2’s complement 

1.25 microsecond cycle time 

8K 3 2 -bit words 

o Accumulator - 16 bits 

o Lower Accumulator - 16 bits 

o Program Counter - 16 bits 

o Address Register - 16 bits 

Two Types : 

(1) External 

(2) Programmable 

o Add/Substract/Load/Store 
o Multiply 

o Divide 

o D.P. Add/Subtract 

o D.P. Load/Store 

o Parallel and serial inputs data channels 
o Parallel output data channel 

o Direct Memory Access Channel 

o At least 12 discretes 

140 kHz - 32 bits parallel 

3.2 megabits serial 

Arithmetic and Control Unit 

o MOS LSIC’s 

Memory (NDRO Required) 

o Plated Wire 

I/O 

o MOS/Bipolar (hybrid) 


2.5 usee 

10.0 psec 

20.0 psec 
4.0 psec 
4.0 psec 
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the various input signals for display, perform various arithmetic operations, 
provide non-destruct storage, and establish synchronism between various inter- 
faces . 

Each processor controls three displays and communicates with one keyboard 
at a time. It contains the operating memory required for execution of the 
display programs and the memory required for refresh buffering. Prefresh 
buffering is classified as static (fixed format) , and dynamic (that which 
varies) . The display processors perform self test and, with the central 
processor and crew participation, perform other tests on the display subsystem, 
e.g., all characters can be displayed simultaneously under operator control. 

The display processor is interfaced with the central processor through 
the parallel input/output channel interconnected to a standard ACT unit. For 
the preliminary design, it is recommended that the display processor have a 
direct channel with the mass memory. This channel (a serial channel) is 
necessary to retrieve the selected format skeletons for display. Access 
would be under control of the central processor thereby maintaining synchronism. 
This is an increase over the present IMS design but is warranted by having to 
handle the update requirements for three CRTs with any one ACT unit. Without 
this added interface, the retrieval of a format from mass memory could take 
on change to the present IMS configuration. If more time was allowed on the 
data bus and/or an increased ACT memory capacity was provided, there would be 
no need for the additional interface. 

All three keyboards are seen by each of the processors. Any keyboard can 
select any display; however, only one keyboard can be in control of a given 
display at any one time. The priority is on a first-come, first-served basis. 

The interface of the refresh controller with the refresh memory is through 
the parallel direct memory access channel. The frame time for refreshing each 
display is under control of the processor via a closed loop interrupt scheme. 
This allows the processor to address and present (blank or unblank) the data 
on the selected display (s) . 

Display Controller Electronics 

The display controller electronics reads the format display control words 
from the refresh memory in the display processor and decodes these to drive 
the voltages for CRT control. It contains the digital and analog circuitry 
to convert the control words (three) to analog deflection and video intensity 
signals. The basic timing is contained in the display controller electronics. 
Refreshing at 50 times per second is performed under control of the display 
processor. Figure 5-5 presents a block diagram of the display controller 
electronics . 

The CRT deflection amplifiers are supplied their signals from digital to 
analog converters. Either alphanumeric characters, symbols, or graphics can 
be displayed at any usable location on the CRT face by use of vector, character, 
and conic signal generators. Beam positioning, together with translations or 
rotation, is also programmed in the same manner. 

A relationship between beam movement and intensity exists. To accommodate 
equal intensities for various displays, either constant write rates or beam 
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FIGURE 5-5 Display Controller Electronics 











compensation is required. The relative merits of each of these for the 
shuttle application has not been evaluated. 

Two methods of displaying graphical data by vectors are possible. The 
first uses point-to-point connection of line segments. With this method, 
the initial and final x and y points are given. Incremental changes in the 
x and y values continues until the final and incremented values are equal. 

Either up/down counters or adders/subtractors can be used. 

The second methods uses vector magnitude and angle. The starting point 
of the vector is provided along with these. The vector can be drawn by using 
a ramp generator from the initial point with the direction controlled by the 
x and y digital to analog converters. 

Constant writing speed is obtained using the ramp. The length of time 
to write a vector is proportional to its magnitude. 

A solid state read-only memory provides the symbol library. It contains 
the stroke control bits/words to generate the x and y deflection and intensity 
controls. This digital information is used to control the line segments or 
strokes to form the symbols. 

A number of ways exist to organize the symbol generator. One of these 
is to obtain the ROM symbol starting address by decoding the character field 
of the control word. This address can be placed in an address counter. The 
readout of the ROM would be the Ax, Ay, and intensity information. The 
address counter can be stepped at time intervals to read out the succeeding 
strokes. The various sized symbols and intensities can either be selected 
from the ROM word or by gain control of the deflection signals. 

An alternate method requiring less ROM storage would be to time-scan each 
ROM word output in either a weighted or nonweighted manner and to derive the 
sequential strokes in this fashion. 

Sine and cosine waveforms are used to generate different conics. These 
can be derived either digitally, using ROM's, or by analog means, as from 
system clocks and harmonics. Placing sine and cosine signals of equal amplitude 
into the x and y deflection circuits yields circles; unequal amplitudes give 
elipses. Various conic radii required in either symbols or graphics can be 
obtained by using attenuators or frequencies controlled by the decoding of 
the word format and display timing. 

Rotation of elements of the display are accomplished through the implemen- 
tation of the following equations: 

= Y 0 sin 0 + X Q cos 0 

= Y 0 cos 0 + Xq sin 0 

where and Y]_ are the rotated coordinates, X Q and Y are the initial coordi- 
nates, and 0 is the angle of rotation. 

The mechanics of obtaining this rotation is that of driving digital to 
analog converters with digital values of the sine and cosine of the desired 
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angle of rotation as obtained from a RCM. The reference voltages for these 
converters are supplied from the x and y deflection voltages obtained from 
position and stroke information. 

Intensity control circuitry provides intensity levels required by the 
display control words and a means by which uniform intensity or a change in 
brightness level can be obtained. Blinking at 1Hz, under control of the bit 
in the control word, is provided. 

Operational amplifier summation of analog signals provides a means of 
combining the generated deflection voltages. In the baseline approach, 
depending upon CRT positioning capability, three display tubes are driven by 
one display generator by unblahking the addressed intensity circuits. The 
operation with the display processor is done synchronously such that the 
assignment of data words is performed according to a time staggered refresh 
method. 

Various techniques utilizing electrostatic character formation or 
multiple digital-to-analog conversion channels, with possibly more generators, 
can reduce the logic speed and analog circuitry bandwidth. A cost effective- 
ness study to determine the optimum way is beyond the scope of the present 
effort. 

Microprogram control is suggested in the display electronics control. 

Such an approach would offer advantages in the design including feasibility 
for changes and possible reduction in amount of logic and power. The format 
words could be examined, decoded and used to obtain micro-instructions 
necessary to perform the sequences attributed to each required action. 

The operations involved in generating a symbol always involve the acqui- 
sition of a bsic control word type. In the case of a vector mode (3) or a 
vector perturbation mode (6) (see Section 5.2.1), the second control word 
type is additionally required. Symbol generation (mode 2) requires the third 
control word type in addition to the basic. As indicated earlier, up to four 
symbols can be generated with each third word type. Additional words are 
required for greater numbers of symbols. The display electronics steps one 
character position in the X axis upon completion of each character. Sufficient 
buffering is envisioned to ensure the availability of control words if needed 
on a look-ahead basis. Parity checking on the words is performed. Interrupts 
are used to alert the display processor to any errors detected, and/or end-of- 
message signals. 

A typical mechanization for the display controller electronics is shown 
in Figure 5-6. The control is implemented through micro -programming involving 
the micro -operations shorn in Figures 5-7, -8, and -9. The CRT display provides 
amplification of the signals to deflect and gate the cathode ray tube beam. 

It also contains the high voltage conversion and control circuitry needed for 
an electromagnetic, electrostatic system. Linearity correction is provided 
for both x and y deflection signals . 

Built-in test capability is provided with photodiodes placed at the 
perimeter of the display. These diodes periodically receive the team and pro- 
vide an indication of status of the beam and ability to position. 
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Figure 5-6. Typical Implementation of Display Controller Electronics 
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Figure 5-9. Data Word 2 Micro-Instructions Flow 
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Other failure detection methods involve both test patterns and the 
capability of multiple CRT display of identical information. These are 
accomplished on a demand basis with crew participation. 

Keyboards 

Each of the three keyboards (see Figure 4-11) provides the numeric and 
special keys by which the crew performs command and display actions . These 
keys enable the selection of a display and of display formats. One keyboard 
communicates with one display at a time. The functions of the keys are: 

(A) 0-9 Numerics - Provides decimal data keys 

(B) ENTER - Commands keyboard entry and/or advance checklist 

(C) CLEAR - Clears latest keyboard entry 

(D) AUTHORIZE - Enables display override to present a new display 

(E) Plus, Minus, E. N, S, and W - Provides special keys for sign and 
direction 

(F) INCREASE, DECREASE - Permits crew adjustment of variables, or slew 
of checklist 

(G) Display Selector (I, II, III, IV, V) - Selects one of five displays 

To provide these functions, no logic is required at the keyboard. The 
selection of a display CRT causes the linkage, if available, of a particular 
display processor to the keyboard. If not available, a CRT indication is 
provided. All required logic is contained in the processors. 

A keyboard retains control of the last display selected. This approach 
does not require keyboard priorities. 

Double pole switches are required to provide a dual, independent indica- 
tion to the processors. 

5.2.3 Software Organization 

The information below has a twofold purpose: (1) to demonstrate software 

feasibility of the concept, based on the DMS configuration selected, and (2) 
to provide sufficient detail for computer sizing (speed and memory) . 

The DMS configuration along with the display processor permits storage 
in three unique locations: mass memory, central processor, and display processor. 
To organize the software and to estimate memory sizes resulting from display 
requirements , an allocation of the various functions was first performed 
(Figure 5-10). In tabulating these functions, a number of other functions 
were considered already resident in the central processor: 

(A) All 2-digit command execution routines, e.g., the routines for 
opening and closing valves and/or switches. 
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FIGURE 5-10 - "Functional Allocations 






(B) All caution and warning routines. 

(C) All routines for extracting measurements. 

(D) Storage for all measurement data. 

Furthermore, it was assumed that, 

(A) All command execution routines are ordered, i.e., addressable given 
a start location and a delta. 

(B) All measurement data are filed and addressable by subsystem. 

The software organization is structured to be modular and consistent with 
the functions listed in Figure 5-10. Two types of modules were defined: 
resident and transient. The resident modules are those programs which are 
stored in the processor throughout the mission. The program modules and 
routines for both the display and central processors are listed in Table 5-5. 

The listing includes both the resident and transient program modules, routines, 
and tables; thereby including anywhere from one to five sets of approximately 
500 transient data sets stored in mass memory. 

To demonstrate feasibility, each of the program modules is discussed below 
in sufficient detail to show throughput and compatibility between modules and 
the various subsystems. 

Display Processor 

The preliminary design of the operational program for the display processors 
consists of the seven basic modules listed in Table 5-5. 

Executive and I/O Modules 

The executive module is relatively simple when compared to that required 
by the central processor. This results from the limited amount of real-time 
requirements. A real-time clocking function is used primarily to aid in self 
test and to provide a point of reference in the program. Mission timers may 
use this clocking function, however, long term synchronization will be under 
control of the central processor. 

In general, the display program synchronization is provided via the inter- 
face. For this reason the I/O module is combined and presented with the execu- 
tive (Figure 5-11). 

The functions performed by the executive, as seen in Figure 5-11 are 
relatively straightforward. Typically the executive consists of a power-up 
routine with transient error checking, program arid I/O initializations, and 
a simple job-tasking routine for completing initiated jobs and for the 
execution of routines other than those initiated by interrupts. 

The I/O module consists of those functions initiated by interrupts. These 
interface functions and their organizations are discussed in the following 
paragraphs . 
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TABLE 5-5. - MODULAR SOFTWARE ORGANIZATION 


Display Processor* : 

Executive Module - 

Power-On Sequence 
Transient Recovery Sequence 
Built-in-Test Monitoring Routine 
Synchronization and Program Control 

Keyboard Module - 

Input Decoder Routine 

CRT Address and Control Routine 

2- Digit Input Tasking Routine 

3- Digit Format Requesting Routine 
1-Digit Header Control Routines 

Update Memory Module 

"Last" Command Update Routine 
System Measurement Update Routines 

I/O Module - 

ACT/ CRT Interface Control 
Mass Memory Interface Control 
Refresh Controller Interface 
Keyboard Interface Control 

Self-Test Module 

Utility Module 

Refresh Memory Modules 

Centra l Pro ces sor : 

Display I/O Routine 

Decoding and Lock-Up Routine 

Format Fetch and Transmit Routine 

2-Digit System Command Routine 

System Measurement Select Routine 

Display Monitor and Reconfiguration Routine 
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1 


ACT Interface 

i 

Twenty-five times per second, the ACT, which is time- synchronized with 
the central processor, interrupts the display processor. Each time this 
occurs, I/O data (Input: 124 32-bit data word. Output: 31 32-bit data word) 

are transferred between the ACT and the operating memory. The input data 
are termed dynamic (24 times per second) or quasi-static (once per second) . 

The output data, which consist of requests on the central processor, supporting 
data, and monitoring information, are interfaced at a constant rate (5 times 
per second) . 

To describe the organization of the input data, they are classified by 
rate: 

Group A: Dynamic Data 

Group B: Quasi- static Data. 

Both groups consist of three sets of data, one set per display, 3 displays 
per processor. 

With the exception of caution and warning information, Group A data are 
considered to be made up of all non-discrete signals. Each set of these 
measurements (3 in all) can consist of up to 60 15-bit words, although this 
word configuration is not mandatory (i.e., rather than 60-60-60, they could 
be grouped 40-30-110) . The location of each signal within the data block 
corresponds to an address stored in the processor, although the addresses 
and the routines for scaling and updating the refresh memory to these data 
are transient. For purposes of this study, the remainder of the data words 
(44 32-bit words) are reserved for caution and warning, timing information 
and control. 

The Group B data block also consists of three sets of data. Each of 
these sets is made up of two sub-sets, one representing discretes and the 
other non-discrete data. The organization of the quasi-static analog data 
is typical of that for Group A. In the case of discrete data, each word 
represents a class of discrete information, e.g., the first word represents 
a class of discrete information, e.g., the first word may represent solenoid 
valves (up to 30 valves per 32-bit word plus one bit for parity and one for 
noting subsequent changes) . In this manner, the symbol corresponding to the 
state of the discrete can easily be changed, e.g., in the case of a valve: 


one : 

Open : 

-0- 

zero : 

Closed : 


In the next case the 

word may represent pressure regulators, i.e., 

one 

Open 

n 

zero : 

Closed: : 

m 

Seven words per set are reserved 
23 words for caution and warning 

for discrete data of this type. This 
information and control. 
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The output data are organized as follows: 

A. One word for locating measurement data, per 2-digit request (this 
word plus the table location in the central processor sets a pointer 
to the measurement or to the routine for securing the measurement) . 

B. One word for locating the routine for executing a 2-digit command 
(typical of item (A)). 

C. One word for locating the starting address in mass memory for 
retrieving format data. 

D. Three words (one for each display) are reserved for discrete BIT 
(built-in- test) information. 

E. Six words are reserved for analog BIT data. 

The remainder of the words are used for control and to transfer various 
operator input data, e.g., a position update consisting of latitude and 
longitude. Based on the turn-around time, an output rate of five times per 
second was selected. 

Caution and Warning Interface 

The caution and warning interrupt is generated by the central processor 
and is considered asynchronous. In the event this interrupt occurs, the 
header changes and blinks and acceptance of an "Authorize" key- in for a format 
change-over is initiated. 

Mass Memory Interface 

Any mass memory interrupt is predictable (with the exception of a random 
error) and thus the loading of mass memory data is basically under control 
of the display processor. This limits the likelihood of loading errors. The 
input data are divided into three groups of information: static, dynamic, and 

operational. The static and dynamic data blocks consist of the display control 
words and the operational data block, the supporting routines and tables. The 
static and dynamic data are read into one of three dedicated memory banks (one 
per display) , with the provision that these banks are overlapped with the CPU. 
The operational data are loaded in a common memory in which the resident 
programs reside. The initiation of a mass memory interrupt (format request by 
a crew member) is considered random with little or no affect on the duty cycle 
to the period between interrupts. 

Refresh Controller Interface 

The refresh controller interrupt is a feedback signal indicating that the 
controller has just completed a refresh cycle for one of the three displays. 

This interrupt is initiated whenever the controller has sensed an end- of -message 
display control irord. Using this technique allows the processor to control 
the refresh frames and, moreover, provides the means for update synchronization 
(e.g., update every other frame permits 25 updates per second). 
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Keyboard Interface 

Each processor is interfaced with three independent keyboards and conse- 
quently will receive three independent interrupts. These interrupts will 
occur asynchronously and could occur simultaneously. Priority is initially 
based on a firt-come, first-served assignment. Thereafter, the keyboard can 
relinquish control (assignment of a display) by a single command. 

The occurrence of interrupts on these lines is considered relatively slow 
(one per second per keyboard) and, consequently, does not impact the duty cycle 
Furthermore, it is assumed that all keys interrupt the processor, with the 
possible exception that the display select keys could be discrete lines. 

Real Time Clock 

The real time clock interrupt is considered part of the executive program. 
For lack of specific information, a 32 times/second interrupt is considered 
adequate. Transient interrupt counters are added to aid in the detection 
and isolation of noise on the interrupt lines. 

Keyboard Module 

A typical program module for the keyboard input is diagrammed and pre- 
sented in Figure 5-12. Because of the requirement that any keyboard can 
select any display, three of these modules (or equivalent) are needed in each 
processor. 

The functions performed by these modules are in conformance with the 
requirements outlined in Section 3.0. The data presented in the diagram are 
self-explanatory, with the possible exception of the 2-digit routine. This 
routine is used to determine if the input is to be transferred to the central 
processor (command execution routine) or to be used by the local processor 
(a special routine included with the format of interest) . If the input is 
of the command execution type, the request is also logged in the "last command" 
(historical) data matrix. 

Update Memory Module 

The update memory module consists of those routines used to provide two 
types of updates. The first update type is the measurement of the variables 
with respect to time. This type of information is derived via the central 
processor and is used by the crew to determine the value or condition of the 
variable. 

The other update type which is applicable to most variables is the value 
or state to which the measured variable was last commanded. This information 
can only be achieved through having recorded the crew's previous command. In 
this manner, the crew is able to compare the present measurements to the last 
commands. To accommodate this latter update type, a historical matrix is kept 
in the operational memory < The matrix is ordered by rows and columns corres- 
ponding to 3-digit format code and 2-digit command code, respectively. In 
some cases, redundancies appear between formats and for these, transient data 
in the form of addresses must accompany the formats. Otherwise, only the 
starting address in the dynamic memory is required for each variable type, i.e. ; 
two- state, three- state, etc. 
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FIGURE 5-12. KEYBOARD MODULE 
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Self Test Module 


Typical self test routines are scheduled, as well as the results of 
various throughput tests conducted in conjunction with the hardware. Note 
that some cross -monitoring is assumed between the processors for increased 
probability of error detection. Furthermore, automatic reconfiguration can 
only be instrumented via the central processor. Manual reconfiguration, 
however, can be performed- by the operator. 

Utility Module 

This module contains all of the standard utility routines, e.g., b inary - 
to-decimal conversion, sine, cosine, decimal-to-binary, etc. In addition, 
this module contains a variety of routines common to all or many of a series 
of formats, e.g., header changes and scaling routines. In effect, this is 
somewhat a "catch-all" module. 

Refresh Memory Modules 

Refresh memory modules are simply dedicated memory banks (1 set per CRT) 
reserved for the display control words. 

Central Processor 

The organization of the display software in the central processor is given 
in Figure 5-13. The routines and various tables are both transient and resi- 
dent. For this purpose, a mass memory input line is shown. Thus, whenever 
a new format is called for display, or whenever a 100 series format is scrolled, 
data will be received over this channel. 

As previously described, the data block received from the display subsystem 
is encoded by its organization within the block. This is achieved by the magni- 
tude of the 2 -digit keyboard input. The input decoder then simply routes the 
crew updates, BIT data and control words to its destination routines, noting 
that crew updates include the destination address. Special measurements (if 
required) and command execution routines are called by combining the appropriate 
input word with the starting location of the corresponding table wherein the 
address is stored. 

The output encoder is responsible for compacting the data and the control 
words necessary to the display subsystem. This information and its organization 
were discussed earlier in the paragraphs describing the I/O module. To com- 
pact the data as described, it is envisioned that the addresses for obtaining 
the measurement data are first grouped by the required rate: i.e., dynamic 
or quasi-static. Next, the execution of the routines for gathering the measure- 
ment data would be divided into discretes and analog measurements. The dis- 
crete data would then be separated by symbols and ordered in accordance with 
a starting location in the refresh buffer memory. The analog data would be 
ordered in accordance with a corresponding table look-up in the display oper- 
ational memory, assuming that this table is ordered and transient. In this 
manner, the measurements are taken and compacted into the appropriate output 
data block. 
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5-15, - CENTRAL PROCESSOR DISPLAY SOFTWARE 





Mass Memory •' 

The organization of the software in the mass memory is format- oriented. 

In general, each format used during the mission will be stored in mass memory 
and will consist of the following. ; 

(A) Static Data Block - Display control words which are non- time -variant. 

(B) Dynamic Data Block - Display control words in which the data vary 
with time. 

(C) Tasking Routines - Special routines used to interpret and execute 
certain 2-digit keyboard commands . 

(D) Address Listings - Includes starting addresses for tables and/or 
specific addresses when update measurements for more than one sub- 
system are involved and/or routing crew input data. 

(E) Address Tables - Specific addresses where the order is proportional 
to the 2 -digit request. 

5.2.4 Memory Storage and Speed Estimates 

Based on the described preliminary design, estimates were made of the 
memory capacity and speed required for the display processor. Additionally, 
the added display memory capacity requirements for both the mass memory and 
central processor were estimated. These estimates are described below. 

Mass Memory 

The mass memory was estimated first, since all display formats are 
stored in this subsystem and the formats are the basic driving functions. 
Since it was not possible to consider all of the formats individually, an 
alternate methods for estimating the size was used. 

First, all of the formats were placed in the following groupings: 

(A) Checklist Formats - These formats include the header, bar charts 
and n-successive events displayed two at a time. 

(B) Subsystem Management Formats - These schematic formats include the 
header, pictorial and/or graphic descriptors, and subsystem commands 
and measurement data. 

(C) Vehicle Management Formats - These formats include header, pictorial 
and/or graphic descriptors, and system commands and measurement data. 

(D) Index, C/0 and C$W Formats - All of these include both the header 
and text. 

(E) Timeline Format s - These include header, bar charts, and text. 

Having categorized the formats, at least one or two in each group was 
selected for coding. The selection was based on those formats having the 
highest density for display, both static .and dynamic requirements considered. 
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The coding used the three, 32 -bit display control words described earlier. 

An example of the coding used including both 16 and 32-bit control words 
is illustrated in Appendix D. 

In addition to the static and dynamic memory requirements, an estimate 
of the maximum capacity for storing the associated tasking routines, address 
listings and address tables was made. These capacities are given in Figure 
5-14. 


Having estimated the storage requirements for those formats having the 
highest densities within each group, the total requirements was estimated. First, 
the requirement of the formats having the highest density was multiplied by the 
number of formats within each group. This figure represents the total number 
of words per group if all of the formats had the same density. To adjust 
this figure for the variation in densities, a weighting factor was used. 

This factor represents the percent of the high density format to be found 
in the average format. 

The results of this procedure are shown in Figure 5-15. The results indi- 
cate that 302,000 32 -bit words are required in mass memory for the total 
number of formats required for the control/display Concept A. 

The mass memory speed requirements specified by the MS (3.2 x 10^ bits/ 
second) are quite sufficient; however, the data should be channeled directly 
to the display processors rather than over the data bus. 

Central Processor 

The requirements for the central processor was based on assumptions made 
in previous paragraphs. Thus, only those resident and transient routines shown 
in Figure 5-13 were sized. 

The speed requirements imposed on the central processor are well within 
those given for the IMS. This is logical, since much of the load has been 
taken up by the local processor. 

There appear to be no added requirements for the data bus beyond those 
previously imposed by the IMS (Output: 3200 words/sec and Input: 800 words/ 

second) . The only added requirement is that direct channel between the mass:// 
memory and display processor be provided. 

The storage requirements for the central processor are given in Figure 
5-16. The estimates are based on servicing 5 CRTs simultaneously. Estimates 
are based on the assumption that the following are already in the central 
processor. 

(A) Measurement Data 

(B) Command Execution Routines 

(C) Basic I/O (data bus) functions 

(D) BIT Monitoring 

(E) Caution and Warning routines 
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FIGURE 5-14 - ESTIMATED HIGH DENSITY FORMAT STORAGE CAPACITY 
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Display Processor 

The estimates for both memory storage and percent duty cycle are given 
in Figure 5-17. These estimates take into account both the resident and 
transient requirements and are based on each display processor handling 3 
of 5 CRTs simultaneously. 


The duty cycle was based on 
add- time") of 2.5 microseconds 

a processor having a "short -op" (equivalent 
and an interrupt breakdown as follows : 

(A) 

Real Time Clock 

: 32 times/sec. 

(B) 

Refresh Controller 

: 150 times/sec. 

(C) 

Data Bus 

: 50 times/sec. 

(D) 

Keyboards 

: 3 times/sec. 

(E) 

Mass Memory 

: 1 time/sec. 

(F) 

cm 

: 1 time/sec. 


This, coupled with the update rates required for the refresh buffers, produced 
the speed estimates given. 

5.3 CONCEPT B 

Concept B is the second of two preliminary designs considered feasible 
for implementation of the display concept under study. Although only one 
design was required, a quick- look into the application of the dot matrix 
method was made for the following reasons: 

(A) Normally, dot matrix techniques are much simpler in mechanization. 

(B) Typically they use less power. 

(C) No electrostatic deflection (high voltage) requirements 

(D) There is a possible reduction in memory requirements through the use 
of row-column positioning (i.e., 14 bits for beam positioning rather 
than 20 as in Concept A) . 

The basic B design is analogous to that of A. The design uses three local 
processors interfaced with the central processor, mass memory, and keyboards 
in nearly the same manner. The exception is in the structure of the display 
control words, i.e., 16 bits are used rather than 32 as in the A design. 

Based on the limited analysis, the interface between the processor and refresh 
controllers is more complex in Concept B, although functionally it is the same 
as A. In essence, the use of 16 bit control words increases the word count 
by a factor of approximately two (16 versus 32) . Thus twice as many words 
must be operated on to display the same format in Concept B as is the case in 
Concept A. To overcome this the controllers in the B design multiplex their 
inputs on a word by word schedule rather than frame by frame as in A. Thus, 
each of the five displays has its own controller and all of its display 
electronics (Figure 5-18). In this manner, the design is able to meet the 
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failure dictate using only three processors. The primary reason for word by 
word multiplexing is the added amount of time needed at the display using 16 
bits rather than 32, e.g., twice as long to position the beam, or two control 
words. This requirement may be reduced with further study. 

5.3.1 Concept B Summary Description 

A summary of the display characteristics for this concept is provided in 
Table 5-6. It should be noted that the B concept is "hybrid" in that vector 
writing is provided; however, this writing uses magnetic deflection only, i.e., 
no superimposed electrostatic deflection is required. 

The operation of the display system is considered basically the same as 
that for the A design, i.e., two processors on-line and one in standby. 

Each processor would be capable of handling up to three displays. The 
display-processor assignment is the same as in design A, i.e., any keyboard 
can select any display provided another keyboard is not in control. Typically, 
the information transferred and the mechanization between the display processor, 
the keyboard, central processor, and mass memory are the same. The informa- 
tion transfer between the refresh controller and the display processor and its 
interface is organized differently. Four of the five controllers have two 
16-bit input buffers and the fifth has three. In this manner, the control 
words may be multiplexed from at least two different sources and in one case 
three, which is in conformance with the reliability constraints. Thus, 
refresh controllers 1 and 2 can receive and display data under control of 
processor 1, or, in the event of a processor 1 failure, processor 3 (typical 
of controllers 4 and 5 with processors 2 and 3 - but not both) . Refresh 
controller 3 can receive and display data from either processor 1 or 2 
(first-come, first-served), and, in the event of failure, either 1 and 3 or 
2 and 3, depending on which failed. 

The refresh controllers are designed to read alternately in sequence 
their appropriate memory banks within each processor by way of a direct memory 
access channel. With the exception of a 16-bit parallel interface between 
the processor and controller, rather than 32-bit, the display processor has 
the same features as those given in Table 5-4. Furthermore, the organization 
of the static and dynamic memories is assumed to be the same. 

Primary differences between Concepts A and B are the display control words, 
32-bits and 16-bits, respectively. The organization of the control words 
for the B design is given in Table 5-7. Two bits are used to differentiate 
between word types. The basic control word provides for the selection of the 
subsequent mode and the logic settings for the various control gates. Typical 
of Concept A also, the following modes are provided. 

1. Symbol 

2 . Rotate 

3. Circle 

4. High Resolution 

5. Vector Perturbation 

6. Angle Perturbation 

7 . Spare 

Three circle sizes are provided, two sizes of alphanumerics , and a selec- 
tion of specially sized symbols (Table 5-6) . The high resolution mode permits 
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TABLE 5-6. 


DISPLAY CHARACTERISTICS 


Type 

Cathode Ray Tube - magnetic deflection 

Area 

6x8 inches (usable area) 

Resolution 

0.010 inches (10-bit D/A positioning) 

Method 

Dot Matrix 

Refresh Rate 

50 times/second 

Update Rate 

24/second (dynamic) , 1/second (quasi -static) 

White Lines 

90 lines/inch 


Vertical Lines: 6 x 90- 540 lines 

Horizontal Lines : 8 x 90 - 720 lines 

Selectable 

Characters 

Standard Size: *Up to 120 


Double Size: Up to 120 


Special: Up to 120 

Character 
Size (hxw) 

Standard: 9x7 dot grid 


Double: 18 x 7 dot grid 


Special: 18 x 14 dot grid 

Selectable 

Character 

2880 standard size characters 

Positions 

(density) 

Non- overlapping rows: 36 

Non- overlapping columns: 80 

Writing Speed 

250,000 inches/second 

Intensity 

Two levels (8000 ft. Lambert environment) 

Display Control 

Three, 16-bit words, seven modes of operation 

Special 

Flashing at 1 Hz and line dashing capability 

1 


* 8 slots reserved for control 


5-47 





<D (/) 
■M rH 4-> 
rt +-> ctf 


ft O O rc! 

(D -H 4-1 
l/> MH ,- d 

•H 0) (D 

■s f 

tJ *h ro 

3 i/i bo h 

<-i a 3ft 


5-48 


TABLE 5-7 - ORGANIZATION OF THE CONTROL WORDS FOR B DESIGN 




the positioning and vectoring of the beam to a resolution accuracy of 10 bits, 
but requires two data words, one for X and one for Y. The vector perturbation 
mode increments the previous vector by a AX of Af amount equal to the count 
set in the No. -of -Increment bit positions. The angle increment mode will rotate 
about the last blanked position in increments of A6 and draw the last unblanked 
vector. This is permissable since all of the data reside in different registers 
within the display electronics. 

The word type (basic and data words 1, 2, and 3) is identified by the two 
bits shown in Table 5-7. The remaining bits in the basic word are typical of 
those described in Concept A. Data words 1 and 2 are normally used to position 
the beam in a row- column matrix (72 x 80) . If, however, the high resolution 
mode is selected, data words 1 and 2 are used explicitly to position the beam 
in x and y, respectively with 10 bit resolution. Similarly, if the rotate mode 
is selected, data words I and 2 represent the sine and cosine of the argument. 

On the other hand, if the angle perturbation mode is selected, data word 1 is 
interpreted to be the incremental angle, in which case the sine and cosine 
values are derived from 2 ROMs. Data word 3 is used solely to select (address) 
the character within the chosen size: A, B, or C. 


(A) 

A: 

Normal 

(B) 

B: 

Double 

(C) 

C: 

Special 


As in Concept A, each processor can handle up to three displays. A quick- 
look estimate of the timing requirements to achieve this indicated that more 
words must be processed due simply to the reduction in the word size (32 bits 
to 16) . This being the case, multiplexing the control words at the controller 
allows for overlapping the processing and should be sufficient to permit control 
of three displays . This area does require more' study effort . 

The interface between the processor and controller is closed- loop, 
using an interrupt scheme. An interrupt is initiated whenever an end- of -message 
occurs and the constant -block-size counter cycles through zero, i.e., the con- 
troller must cycle through identical block sizes for each display to maintain 
synchronization for updating the dynamic memory blanks (note that updating 
occurs any time the dynamic banks are not being read, which could be implemented 
using two interrupts or the same interrupt twice) . 

5.3.2 Display Elements 

The display subsystem under the B design consists of the following major 


elements : 


(A) 

Display Processors (3) 

(B) 

Display Controller Electronics (_5) 

(C) 

CRT Displays ( 5) 

CD) 

Keyboards ( 3) 


5-49 



As in the A design, these elements are interconnected such that no one 
single failure is cause for a complete subsystem failure (Figure 5-18). Both 
manual and automatic reconfiguration are provided. 

Display Processors 

The general characteristics of the display processor are the same here 
as those given in Table 5-4 with one exception. The direct memory access 
channel need only handle 16 bits parallel; however, the data rate for this 
channel must double, i.e., from 80 kHz - 32 bits parallel to 160 kHz - 16 bits 
parallel. The reader is referred to the display processor description in para- 
graph 5.2.2. 

Display Controller Electronics 

The display controller electronics reads the format display control words 
from the refresh memory located in the display processor. These data are 
then decoded and processed in accordance with the selected modes to derive 
the voltages required by the CRT electronics. - - 

The preliminary design of this unit is shown in Figure 5-19. Micro- 
programming is recommended for control because of its flexibility and inherent 
physical advantages. For these same reasons, read-only-memory (ROM) devices 
are used to achieve accurate digital voltages for beam positioning and are also 
used to derive the pulse trains (video modulation) representing the various 
symbols which are used to drive the CRT video channels. 

To illustrate the various operations involved within the controller, a 
simple microprogram sequence is illustrated, Figures 5-20 and 5-21. 

In viewing these figures, it can be seen that certain control statements 
are examined whenever data word 3 is read in. This is explained by Figure 
5-22, which demosntrates that, of the normal 7-bit code used to address 
symbols in data word 3, a few codes are used for internal control such as spacing, 
start new line, end- of -message, and test codes. 

CRT Display 

The primary difference between the A and B designs in the display 
electronics is that A uses electromagnetic beam positioning in conjunction with 
electrostatic deflection. In concept B, the latter is not required, thereby 
reducing deflection voltage requirements. However, because of the video 
multiplexing required for the dot matrix technique, the bandwidth on the 
z-channel is significantly increased and furthermore requires more sophisticated 
synchronization between all of the axes. Otherwise, both designs perform the 
same basic functions. 

Keyboards 

The keyboard design is the same as that described in paragraph 5.2.2. 

5.3.3 Software Organization 

With the exception of handling 16-bit words rather than 32-bit words, 
the basic structure of the software for Concept B is assumed to be the same 
as for A. 
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FIGURE 5-21. DATA WORDS 364 MICROPROGRAM INSTRUCTION FLOW 
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FIGURE 5-22 , - TYPICAL ADDRESSABLE SYM30LS 
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5.3.4 Memory Storage and Speed Estimates 

Most of the quick- look effort in this area was concentrated on evaluating 
the effect of using 16-bit display control words over that of the 32-bit words. 

To make a meaningful evaluation between the two word lengths, formats 
were selected from the various groupings described earlier and coded lasing 
both word lengths . These data were then tabulated and compared to show whether 
any improvement would be made in storage requirements using a 16-bit word 
organization over that of 32-bits. The results indicated an improvement any- 
where from 2 to 25 percent, Table 5-8. The variation in percentage is primarily 
attributed to writing single characters using a 32-bit word rather than a 
16-bit word, e.g., Format 979. 

To estimate the impact on mass memory, the percentage improvement per group 
was multiplied by the number of formats in that group and then weighted by the 
complexity factor. This computation showed an estimated reduction of 35,100 
32-bit words or approximately 12 percent improvement. 

Such an improvement is worthy of further consideration, recognizing that 
the failure dictate and the 100 percent design allowance boosts this to a 
requirement of 212,000 32-bit words. On the other hand, such ramifications 
as increased programming required for the 16-bit word approach must be considered, 
i.e., the number of display control instructions is doubled. Additionally, 
either software or hardware is required to pack and unpack the 32-bit I/O (data 
bus) data. More addresses may have to accompany each of the formats due to the 
increased number of instructions. All of these represent trade areas that 
would be required in selecting between concepts A and B. 
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TABLE 5-8 - STORAGE IMPROVEMENT WITH WORD LENGTH 












6.0 DMS IMPACT AND PROBLEM IDENTIFICATION 


6.1 INTRODUCTION 

The following section summarizes the impacts of the alternate control/ 
display design concepts upon the DMS configuration and describes problems 
identified during the analysis. Problem areas identified include tradeoffs 
yet to be performed, as well as design, development, and operational usage 
problems. 

6.2 DMS IMPACTS 

The most significant impact on the DMS is upon the mass memory. To esti- 
mate the magnitude of this impact, the Phase B Space Shuttle DMS mass memory 
requirement shown in Table 6-1 was compared with an adjusted Phase B DMS 
requirement derived by substituting the display/control concept requirements 
for equivalent portions of the Phase B DMS estimates. The calculation was 
made in the following manner. The total Phase B DMS mass memory requirements 
were reduced by subtracting the following integrated control/display elements: 

(a) Display Format Control Tables (2,000 words) 

(b) Display Format Skeletons (29,800 words) 

(c) Keyboard Input Control Tables (2,800 words) 

(d) ID$C Programs (3,781 words) 

This yielded an adjusted mass memory requirement (without controls and 
displays) of 140,000 32-bit words. To this adjusted requirement was added 
the estimated mass memory requirement for the control/display concept under 
study (Figure 5-15), reduced by the estimated 12 percent to be gained by using 
16-bit control words; i.e., 266,000 equivalent 32-bit words. The total, or 
approximately 400K words, represents the DMS requirements with the least 
demanding of the two control/display alternates. 

If the estimated requirements are further adjusted by a 100 percent 
design allowance, the requirements are approximately 400K words and 800K words 
for the Phase B DMS requirement and the Concept B requirement, respectively. 
Since this estimate is for one of a triply redundant memory system, when the .. 
requirements are adjusted for failure provisions, the total mass memory re- 
quirement is 1,200K and 2,400K for the two systems, respectively. The impact, 
then, is that the control/display concept, at a minimum, effectively doubles 
the DMS mass memory requirement. These data are summarized in Table 6-2. 

Table 6-2. Comparison between Phase B DMS Mass Memory Requirements 

and Concept B Mass Memory Requirements 


1 

DMS w/o 
C/D 

Memory 

C/D Memory 
Reqt 

DMS + 
C/D 

Memory 

DMS + 100% 
Design 
Allowance 

DMS with 
Triple 
Redundancy 

Phase B 
Design 

140K 

37K 

177K 

= 400K 

~ 1 ,200K 

Concept 
B Design 

140K 

266K 

400K 

~ 800K 

~ 2 ,400K 


6-1 



Table 6-1. Baseline DMS - Estimated Mass Storage Requirements 


TABLES ■ 

32-BIT WORDS 

MISSION PHASE PROFILE 

. 8 ,000 

SYSTEM STATUS TABLE 

1,750 

TASK CONTROL 

1,600 

PROGRAM CONTROL 

2,560 

MISSION PHASE CORE MAP 

2,400 

MISSION PHASE DRUM MAP 

600 

CONTROL ACTION TABLES 

6,000 

TEST POINT MONITORING LIMITS 

5,144 

DIAGNOSTIC ANALYSIS DATA 

2,400 . 

SYSTEM RECONFIGURATION TABLES 

728 

DCM RECONFIGURATION 

744 

DISPLAY FORMAT CONTROL TABLES 

2,000 

DISPLAY FORMAT SKELETONS 

29,800 

KEYBOARD INPUT CONTROL TABLES 

2,800 

PROGRAMS 

EXECUTIVE 

2,880 

COFI 

3,468 

ID$C 

3,781 

SUBSYSTEM SOFTWARE 

2,100 

GUIDANCE , NAVIGATION $ CONTROL • 

18,300 

COFI DIAGNOSTICS 

30,000 

RECORDING 

STORAGE 

50,000 

TOTAL MASS STORAGE 

177,055 
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The second significant impact on DMS design resulting from the display/ 
control design concept is the necessity to provide a direct access channel to 
the display processors. This necessity arises from the choice of local proces- 
sing rather than central processing for the control/display subsystem. If format 
data were transmitted over normal data bus channels, either an undesirable 
increase in format retrieval time would result or the DMS would have to be re- 
designed to allow more time on the data bus and/or to provide greater memory 
capacity in the ACT. 

The selection of local processing reduces central processor requirements 
such as size, timing (or duty cycle), instruction repertoire, and I/O (or 
data) rates. The requirements imposed on the central processor using Concept 
B are less than those imposed by the Phase B control and display design 
approach. The Phase B central processor design was considered to include 
provisions for (a) the measurement data required by the formats, (b) the 
routines for executing system commands initiated from the keyboard, and (c) 
the basic I/O structure. 

Both preliminary design concepts A and B kept within the data bus data 
rates specified by the baseline DMS configuration, given as follows: 

(a) Processor-to-display : 

124 32-bit data words @ 25 times/second 

(b) Display-to-processor : 

31 32-bit data words @ 25 times/second 

Based on the assumptions made during the study, no other major impacts 
on the selected baseline DMS configuration were found resulting from the pre- 
liminary designs. It should be noted, however, that elimination of the stored 
checklist formats would decrease by half the anticipated impact of the display/ 
control design upon DMS mass memory requirements and would lessen software 
requirements by at least 40 percent . 

6.3 PROBLEM IDENTIFICATION 

No catastrophic problems were revealed by the preliminary designs. How- 
ever, several areas which require further study and evaluating, but which were 
beyond the scope of this study, did arise. These problems are discussed below. 

6.3.1 Stroke vs Dot Matrix Techniques 

While the analysis revealed that both the stroke and the dot matrix 
techniques are feasible techniques for the generation of the formats developed 
during the study, further tradeoffs are required before selection of one 
technique over the other. These tradeoffs include consideration of relative 
versatility (the dot matrix technique is much more restrictive to data format 
composition), power requirements, software requirements (complexity and magni- 
tude) and cost (together with related reliability and simplicity of design 
factors) . 
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6.3.2 Direct Access Channel 


A tradeoff is required between the provision of a direct access 
channel between the display processor and mass memory and the provision of 
more time availability on the data bus and/or an increased ACT memory 
capacity. This assumes that increased access time to successive display 
formats is undesirable, from the operator's standpoint, an assumption for 
which supporting data are not yet available. 

6.3.3 Software Programming 

The large number of formats estimated for the Space Shuttle system 
presents a potential problem in software development. Consider 500 transient 
programs being operated on by one resident program. Furthermore, consider 
that the 500 programs were coded by 500 different programmers. What is the 
probability that all or any of the 500 programs can be operated on success- 
fully by the resident program? In essence, this reasoning leads to a need 
for a "hard core" standardization, or even better, a compiler language for 
aiding in the programming of formats. Without the aid of either of these, 
the feasibility of the control/display concept becomes marginal due to the 
economics of programming, checkout, and software verification. 

The standardization or compiler referred to must be designed to: 

(a) Permit ease of coding by the programmer(s) 

(b) Provide for separation of static and dynamic data 

(c) Compact the dynamic data in a manner readily accessible for 
updating by the resident program. 

To specify a compiler and a "user's" manual in accordance with these 
design requirements is beyond the scope of this study. However, certain 
recommendations can be made for further study and development. 

First, it is recommended that the following preliminary design pro- 
cedures be used to develop the standards: 

(a) Categorize all update data required by the formats and analyze for 
commonality; e.g., 2-state discretes, 3-state discretes, analog 
bar charts, analog tape dials, analog magnitude, etc. 

(b) Allocate these data to specific (addressable) locations in the 
dynamic memory. 

(c) Develop specific routines for testing the presence of the data and 
for updating these locations whenever present. 

(d) Categorize historical data, i.e., crew last-commanded component 
states stored in the historical matrix, in terms of 2-state 
commands, 3-state commands, etc. 

(e) Develop specific routines for updating the corresponding symbols 
and for accounting for ambiguities between formats (a command 
displayed on more than one format) . 
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(f) Develop universal (all 500) method for storing and interpreting 
the queuing and table lookup data with the formats. 

After developing the resident routines, format storage should be 
organized in a compatible manner. It should be noted that a 5 to 10 percent 
reserve for variations in basic standards could be required. The basic 
formulation suggested for the storage media should correspond to that 
described in the preliminary design. 

To recap, the resident routines for updating dynamic memory should be 
developed and a standard format storage medium, compatible with those routines, 
should be structured. With this in mind, a compiler language could be 
developed for the generation of formats which would be compatible with the 
resident program. 

A procedure could be used for compilation, either the "brute force" 
method (draw it on paper, punch cards, compile, check listings, etc.) or an 
on-line CRT terminal. The latter would reduce turnaround time and would give 
the programmer a quick look at the format on the display. A better recommen- 
dation, however, would be the use of a dedicated format generator. To 
accomplish this, one of several available graphic display generators could 
be integrated with the compiler in the generator processor. In this manner, 
the programmer could, off-line, input the data in the form that it would 
actually appear on the display. Furthermore, he would have the capability 
to make immediate changes and to separate both static and dynamic data. 

Upon completion of a satisfactory format, the programmer would then simply 
request the compilation (or translation) into the language used for storage 
in mass memory. 

To test this approach, Format 510 was generated on the Information 
Displays Incorporated (IDI) IDIIOM display generator. The result, drawn by 
graphic plotter, is shown in Figure 6-1. It was found that the entire 
format could be drawn in less than an hour, less time than required to make 
the original pencilled drawing. Coding into a format compatible with the 
XDS 9300 computer was automatic. 

6.3.4 Operational Utilization 

Several problems arose concerning the operational utility of the control/' 
display concept under investigation. Of greatest impact on the overall DMS 
design was the decision to store and display operational checklists. Time- 
line analyses showed that within the assumed available time and operational 
procedures, both stored and printed checklist approaches were feasible. The 
use of printed checklists greatly increases the amount of "flipping" between 
formats required to complete most operational procedures, but it cuts in half 
the increase in DMS mass memory required to utilize the control/display 
concept. No data are available to determine the amount of savings in 
lowered error rates, lower operator fatigue and reduced training which may 
be gained by the use of stored checklists - data which must be gained 
through controlled simulation experiments. 
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Figure 6-1. Display Format Developed on IDI Display Generator 
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During the development of the sample formats, a number of decisions were 
made based on expert judgments concerning such factors as maximum permissible 
format density, symbol size and shape, organization of data, etc. Within the 
context of the study, it is believed that the decisions made were in keeping 
with shuttle operational requirements and good human engineering standards; 
however, there is a strong need for systematic experimental verification of 
the integrated effect of the assumptions and for the development of a 
data base built around this type of display approach to facilitate its use 
in the future. 

Of course, no data are available concerning the acceptability of this 
approach to trained pilots/astronauts previously trained on systems utilizing 
dedicated controls and instrumentation. 

All of the above considerations indicate a need for man-in-the-loop 
simulation of the control/display concept to permit realistic further 
evaluation and development of the concept. 


6-7 



7.0 APPLICATION OF CONTROL AND DISPLAY CONCEPT TO THE NORTH 
AMERICAN ROCKWELL - SPACE DIVISION (NR-SD) PROPOSAL 
SHUTTLE CONFIGURATION 


This section describes a limited supplemental study performed after 
completion of the main study (Sections 1 through 6) and directed toward 
examination of the application of the control and display concept to the 
NR-SD shuttle configuration proposed in response to NASA space shuttle program 
request for proposal No. 9-BC421-67-2-40P. This NR-SD configuration is 
referred to in this report as NR-SD baseline. 

7 . 1 OBJECTIVE 

This supplemental study objective is to examine application of the 
control and display concept to the NR-SD baseline by defining a mechanization 
approach, impacts and problem areas. 

7.2 WORK ACCOMPLISHED 

The supplemental study was performed in five phases: (1) Review of 

mission and vehicle characteristics, (2) select representative subsystems 
for evaluation and define requirements for the selected subsystems, (3) 
define a mechanization approach, (4) preliminary design considerations of key 
major items of the CRT control and display system, and (5) assessment of 
impact of applying concept to the vehicle. 

7.3 BASELINE MISSION AND CONFIGURATION 

This section presents the results of the review of the baseline mission 
and vehicle characteristics, the selection of subsystems for evaluation, and 
describes the selected subsystems. 

7.3.1 Mission and Vehicle Configuration 

Missions 1, 2 and 3 described in section 1.2.0 of NASA Space Shuttle 
Program Request for Proposal No. 9-BC421-67-2-40P were reviewed against the 
baseline mission defined for the control and display concept study and 
described in section 3.2 of this report. The functions and tasks required 
by the baseline mission were found to encompass those required for Missions 1, 
2 and 3. Therefore, the baseline mission was adopted for the supplemental 
study. 

The orbiter vehicle described in NR-SD shuttle proposal 5D-72-SH-50-3, 
volume III, is used as the baseline configuration for the supplemental 
study. Diagrams of the principal subsystems are provided in Appendix E. 

The NR-SD system was reviewed for the purpose of selecting two sub- 
systems to investigate application of the control and display concept. The 
two subsystems were selected as representative of the range of conditions 
to be encountered in the total vehicle since study resources did not provide 
for defining specific concept application for every subsystem. Selection 
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criteria included expected magnitude of change of adapting to the concept 
and a representative range of data handling and redundancy conditions. The 
Guidance Navigation and Control (GN§C) subsystem is characterized by largely 
digital data handling and processing, a significant crew interface through a 
multifunction CRT subsystem, and critical redundancy requirements. The 
electrical power distribution and control subsystem (EPDC) is almost entirely 
analog, uses largely dedicated controls and displays with only a small inter- 
face to the multifunction CRT subsystem, and has a relatively large number 
of end effectors (remote controlled circuit breakers and power contactors) 
to control. The other subsystems appeared to fall within the range of con- 
ditions represented by the GN§C and EPDC; hence, these two subsystems were 
selected for investigation of application of the control and display concept. 
The Data Processing and Software subsystem (DPS) role in data handling and 
control and display functions involves the DPS as a primary study area. The 
baseline configuration for these subsystems and comparison to Phase B are 
described below. The baseline descriptions are condensed from the NR-SD 
shuttle proposal SD-72-SH-50-3, which is used as the basic data source. 

7.3.2 Data Processing and Software Subsystem 

Application of the control and display concept involves examination 
and possible change to the data processing and software subsystem which is 
central to a significant part of the vehicle data handling. The following 
description of the baseline data processing and software subsystem is 
therefore provided. 

The data processing and software subsystem provides the on-board digital 
computation required to support the vehicle subsystems. The system configura- 
tion proposed by NR-SD shown in Figure 7-1 uses two computer types, the GNf)C 
computer and the modular display electronics (MDE) in several combinations to 
satisfy functional and redundancy requirements. 

Key features of the data processing and software subsystem configuration 

are : 


. Computation tasks are grouped and allocated for separation of high 
development activity and isolation of high traffic data from flight 
critical functions. 

. Display, keyboard and non-GNSC computation functions mechanized in a 
single type, small computer augmented by tape mass memory. 

. No direct exchange of data between computers performing redundant 
functions (multiple cross switching but no cross strapping), low data 
rate and non-interrupt transfer of data, memory protection. 

The hardware elements which comprise the data processing and software 
subsystem include the on-board computers, the mass memories, and the adapting 
input-output elements. A summary of the important design features is in 
Table 7-1. Primary GN§C functions are mechanized in a high-speed, 64,000- 
word main memory, general purpose computer. 
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Figure 7-1. Data Processing and Software Subsystem 


Table 7-1. Hardware Design Features 


features 

Benefits 

Computer interface 
Direct memory access 
input /out pu t 

Modular input/output interface 

PCM decomrnutation 
channel (MDE) 

Concurrent CPU and input/output operation. 

80?/o standard. 20% custom, modular design allows use of off-the- 
shelf equipment in other subsystems. 

On-board decommutation capability for operational flight instrumen- 
tation and payload serial data channel (256 Kb/s, maximum), permits 
on-board performance monitoring. 

Computer features 
Off-the-shelf subassemblies . 

Uses existing subassemblies from military production programs plus 
MSI/LSI devices from same programs for new subassembly. Allows 
use of existing hardware for early fab test ar,o software development 

Memory and register 
protection/preservation 
Floating point hardware 

Retains current register d3ta and protects memory contents in the 
event of anomalies in input power. 

Reduces software preparation and verification costs. Software savings 
exceed hardware cost increase. 

Display processor, symbol 
generator and refresh (MOE) 

Combined electronics for display and computation reduces develop- 
ment costs. 

Phase locked internal clocks 
(GN&C) to Master Trmirig Unit 

Simplest way to avoid relative string drift and accumulated time in- 
accuracies. 

Growth provisions 
Speed greater than 300 kops 
Main Memory— 64K 32 bit 

words (GN&C) 

128 kops required, reserve > 100%. 
30.300 words required, reserve > 100%. 

-8K 32 bit 
words (MDE) 

5400 words required, 50% reserve plus mass memory. 

Input/Output- channels 

100% growth possible within existing LRU by adding required logic 
hardware. 

-3.2 Mbit/sec 
channel (GN&C) 

Provisions for future mass memory without design modification. 

Mass Memory-Tape 256 K words 
40 K bit/sec trans- 
fer rate (MDE) 

Allows smaller mam memory; low transfer rale compatible with avail- 
able tape equipment. 

l SI - large scale integrated 
MSI -medium scale integrated 
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Technical evaluation of the remaining computer functions shows that they 
are not time critical, can be broken into small segments for processing, and 
are not all required simultaneously. Therefore, these functions are distributed 
among several small identical processors with mass memory for program reload. 

The payload data processing requirement of 10,000 32 -bit words is satis- 
fied by the use of a modular display electronics unit with an equivalent of 
8000 32-bit words in the main memory and the tape mass memory. 

The input/output (I/O) interface between the computers and the other 
vehicle subsystems is implemented using a modular design concept to provide 
the flexibility to accommodate changing requirements and permit early computer 
design. The modular display electronics I/O, computing, and display sub- 
assemblies are combined into a single unit, which permits a simple design and 
is feasible because the identified I/O channel requirements are primarily 
multiplexed, serial digital. The I/O to the GN$C computers is significantly 
more complex and subject to change; therefore, these functions have been 
grouped into a separate unit identified as the GN§C I/O buffer. The I/O 
buffer provides the functions of signal conversion, multiplexing, and transfer 
of data to and from the computer memory. The transfer functions are accom- 
plished by using a direct memory access channel which operates independently 
of the CPU, except for initialization. 

The on-board software design approach is intended to provide a single 
design (baseline) program that can accommodate all shuttle missions. The 
flight software structure uses self-contained program modules, all inter- 
module communication being through mutually accessible, common data pools. 

This concept provides isolation of changes in order to control error propaga- 
tion, management change control at the unit level, and elimination of inter- 
module interference in order to simplify program verification. Control and 
scheduling of the individual modules are provided by the executive program, 
the structure of which is identical for all programs and is based on internal 
timer interrupt, fixed time slice, tabular look-up mode of operation devoid 
of external interrupts. This type of executive structure simplifies the veri- 
fication process by providing a repeatable program pattern at fixed intervals 
whenever the intervals are predetermined during the program design phase. 

Table 7-2 illustrates the assignment of programs and requirements to the 
functionally dedicated GN§C computers and MDE's and identifies the memory size, 
speed estimates, and capabilities. 

A brief comparison with the Phase B data processing and software sub- 
system demonstrates the two different methods of solving the processing 
problem. The Phase B approach utilizes a centralized multiprocessor con- 
figuration rather than dedicated. In this configuration the central processor 
is interconnected and interfaced with the on-board elements through a five- 
channel data bus subsystem and acquisition, control and test (ACT) units, 
respectively. A simplified block diagram illustrating the Phase B approach 
is provided in Figure 7-2. 
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Table 7-2. Program Functional Requirements § Memory Estimates 


GfJ&C 


1 

. Function 

Size and (Speed) 

GN&C 


Executive 

3950 

350 

Data pool, subroutines. 

(13.8) 

(0.5) 

input/out, sequencing, 



scheduling, tables 
System status 

2200 


Redundancy management, 

(25.5) 

* 

GN&C, system performance 
monitor, ground checkout 



Flight crew displays 

450 

3600 

GN&C system status, 

(0.4) 

(5.6) 

procedures 

Navigation 

5850 


State vector, attitude 

(2.1) 


reference 

Guidance 

7500 


Steering commands, engine 

(39.5) 


control, abort 
Targeting 

4200 


Flight control 

(19.3) 

2950 


TVC, RCS, digital outer loop. 

(20.1) 


boost blending 
Program services- 

2700 


Uplink, PCM, preflight, 

(5.0) 


system align and calibration, 
interfaces (booster, payload, 
main engine controller, 

GSE interface) 

Unmanned orbiter 

500 


Sequencing, calculation for 

(2.5) 


autonomous flight 
Program loader 


100 

Peak memory loading 

30300 

4050 

(128.2) 

(6.1) 

Machine capability main 
memory 

65536 

8192 

(380.0) 

(296.0) 

Tape memory 


255 K 


PM and Backup GN& 

C MDE's 

~ — r 


Size and (Speed) | 


PM 

8U GN&C 

Executive 

400 

400 

Subroutines, input/cutput, 
data pool, tables 

(0.5) 

(5.0) 

System status 

900 


Non-GN&C system perform- 
ance monitor, annunciator, 
lights, self-check 

(20.0) 


Crew station displays 

3900 


Input/output conversions, 
formats, tables, display 
services, time share GN&C, 
PM, and backup GN&C 

(5.6) 


Backup GN&C 


7.950 

Steer to displays, get-home 
guidance and navigation 

1 


(33.1) 

Program loader 
Tape memory load on crew 
request 

150 

150 


PIM and PLH MDE s 


Size and 


Function 


Executive ' 

Subroutines, input/output, 
data pool, tables 
System status 

Performance monitor, analog, 
discrete, serial limit checks 
Crew displays 
Input/output conversions, 
formats, tables, display 
services 

Payload checkout 
Minimal on board checkout, 
no experiment processing • 
PLH control program 
Ciosed-loop cor.tr ol cf 
attitude, rale, and position 
PLH constraint tables 
Deployment and retrieval 
trajectories, payload 
dependent tables 
Program loader 
Tape memory load on request 



Note.- Sizing is in terms of equivalent 32-bit words, Most GN&C comouter instructions are 16 bits. 

MDE computers are aii 16 bits. Floating point data are 32 or 43 bits and other data are 16 or 32 bits. Speed in KADS. 
MDE— modular displav eiectronics PLM— payload management PM-performance monitor PLH— oayioao handling 


‘Mutually exclusive, 
tape memory load 
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Figure 7-2. Phase B Central Computer System 









7.3.3 GNSC Subsystem 

The Guidance, Navigation and Control subsystem is one of the several on- 
board dedicated subsystems. Briefly, the selected baseline GN§C subsystem 
provides the capability for both automatic and/or manual control over the 
entire mission. 

The GN£C subsystem is divided into three groups of equipments: the 

primary GNf)C, the backup GNfjC and the Aerodynamic Stability Augmentation Sub- 
system (ASAS) . A simplified diagram depicting the overall mechanization, as 
proposed by NR-SD, is presented in Figure 7-3. Additionally, the various 
modes of operation are given in Table 7-3. 

In accordance with SD, the primary GN§C equipments provide: (1) auto- 

matic and manual control capability for all of the flight phases except for 
docking, which is manual only; (2) guidance commands for the control loops; 

(3) steering displays for the crew; and (4) inertial navigation updated by 
star and horizon sensors for autonomous orbital flight and by RF navigation 
aids for rendezvous, approach, and landing. 

The primary subsystem provides for both automatic (command) and manual 
(control stick steering) modes (Table 7-3). The flight control loops used 
with the main engine and orbital maneuver subsystem, thrust vector controls, 
and the reaction control system are closed through the GNOC computers. Aero- 
surface control is provided by the GN§C computers and the ASAS. 

The basic aerodynamic stability of the orbiter is augmented by using 
the ASAS. The ASAS is a conventional type employing body-mounted rate gyros 
and accelerometers. Gain scheduling is provided by a digital air data 
computer and deployable probes. Side stick rotation controllers, rudder 
pedals and trim control allow for manual control. 

The backup GN£C subsystem provides a safe return capability from all 
flight phases. These equipments are separate from the primary subsystem and 
use dedicated sensors and electronics. Backup flight control is manual; 
rotation controller and rudder pedal inputs are used. Steering information 
is displayed on the cockpit CRT's (MDE’s). 

It is interesting to note the difference between this baseline GN§C 
subsystem and the integrated concept (Phase B study) . A fundamental differ- 
ence is the means for data flow. In the case of the integrated concept 
all of the avionics subsystems are interfaced with and controlled by a central 
computer complex via a common data bus. As such, this allows a simple non- 
redundant display subsystem complete access to all of the data within, as well 
as control over, the entire avionics system. 

The baseline approach, on the other hand, divides the various avionics 
functions into equipment groupings wherein the equipments in each group are 
interconnected through conventional dedicated cabling practices. For this 
reason, the dedicated system uses a larger number of controls and displays. 
However, in order to meet the failure criteria (fail-op, fail-safe) over- 
lapping of functions is permitted within certain of the display subsystems 
and, in particular, the MDE's. Of further importance, due to the redundancy 
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Figure 7-3. Mechanization of GN&C 


Table 7-3. Control Modes 


Mode 

Flight Phase 

Characteristic 

Command 

• Boost/insertion (TVC) Orbital (OMS 
TVC.RCS), Entry. Aero. Landing 

• Crew initiates guidance and control modes and monitors — 
control automatic through GN&C computer 

Control 

stick 

steering 

• Orbital (OMS TVC or RCS), Entry, Aero. 
Landing 

• Manual comrol and guidance displays through GN&C 
computer 

• Rate command, attitude hold, and RCS minimum impulse; 
RCS translator.— acceleration command 

Manual 

• Aerodynamic 

• Manual control through ASAS 
Rate command and damp 

Manual 

(backup) 

• Boost/insertion (TVC) Orbital (OMS 
TVC or RCS), Entry. Aero, landing 

• Backup sensor c . and computer; Rate command and damp 

• Direct RCS ;et 
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criteria, is the operational configuration. The integrated system uses 
multiple independent subsystems interconnected to a quad redundant central 
processor via five independent multiple data bus channels. In this manner 
fault detection is achieved by voting on the data and weighing results at the 
various terminals, performing independent parallel processing, and maintaining 
the central processor in overall control. In the case of the baseline sub- 
systems, the GN§C, in particular, operates as three independent strings with 
cross strapping of signals at the force servos and jet drivers, as well as 
the IMU outputs at the processors for initialization and fault detection. 

Fault detection of the processors themselves is done by BITE; otherwise, the 
subsystems themselves are left to detect any faults generated by the proces- 
sors; e.g., note the servo and reaction jet inputs A, B, and C shown in 
Figure 7-2. 

Further differences between the two approaches include the following: 

1. An analog aerodisplay subsystem as well as CRT's is included 
in the baseline approach. 

2. A completely independent backup subsystem is used by the baseline 
approach. 

3. The use of horizon sensors, TACAN, and ILS over that of the multi- 
lateration system used in the Phase B. 

7.3.4 Electrical Power Distribution and Control Subsystem 

The electrical power distribution and control subsystem (EPDC) provides 
distribution, control, and conversion of all electrical power, and, in con- 
junction with the electrical power subsystem, assures power characteristics 
compatible with all orbiter, tank, and SRM requirements. EPDC also provides 
sequencing functions and interconnecting wiring for all subsystems. 

Figure 7-4 depicts the proposed NR-SD orbiter EPDC bus control/distribu- 
tion scheme and its interface with power sources and loads. 

The subsystem is characterized by 28 volts nominal dc buses and 115/200 
volts, 400 Hz, nominal main and inverter ac buses. Three redundant buses 
operate simultaneously; each is isolated to avoid complex paralleling controls 
and to confine power transients to a single redundant string. The essential 
control buses supply sequencer logic power and loads required to initialize 
main bus pcwer from a power-off state. Salient features of the EPDC and the 
candidate hardware types are shown in Table 7-4. 

Comparison to the Phase B EPDC (Figure 7-5) shows similarity of power 
sources and bus structure. The difference of significance to this study is 
the interface with the remote controlled circuit breakers (RCCB) and the 
remote power controllers (RPC) . Phase B provides control to these elements 
from the central data bus of the data control and management subsystem (DCM) 
via acquisition control and test units (ACT) whereas the NR-SD baseline 
typically provides dedicated wire and cockpit switch control of these 
elements . 
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Figure 7-4. Electrical Power Distribution and Control Schematic 
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Table 7-4. EPDC Features 


feature 

Selected Approach 

Equipment/Components 

Power types 
DC 

Aero, boost and 
entry ac 
Orbit ac 

GSE 

24-30 vat load 

1 1 5/200-v. 400-Hz generator 
(MIL-STD-704A) 

115/200 v. 400 Hz central 
inverter system (CSM limits) 
115/2CO-V, 4 CO-Hz 
(M IL-STD-7 04A) 

[fuel cells,"- 150-amp transformer-rectifier, 
!10 amp-hr ba'tfe'nTs.] batierv charger 
; Generators.* generator control unit 

CSM 1250-va 3-phase inverters 
(refurbish-reuse) 

Ac power umbilicals 

Bus redundancy 

Three redundant 

Magnetic latch, hermetic seated power 
contactors 

Redundancy 

management 

Isolated (ac nonsynchro- 
nized— isolation maintained 
from source through load) 
Bus transfer after source 
failure 

Redundant loads powered 
from redundant buses 

Magnetic latch, hermetic sealed power 
contactors 

Load control' 

Hardwired electromechanical 

Magnetic latch, hermetically sealed RCCB's 
RPC's, high-reliability relays 

Power current return 

Structure, multipoint ground 
(single-point ground (or 
signal circuits! 


Sequencing 

Conventional logic-with 
voting inputs and basic 
timing from G.VX computer 

Relays and solid-state logic 

Circuit sensing 
Main ac 

Dc 

Inverter 

Fault 

Over-under voltage I 

Over-under frequency 
Overload * 

Undervoltage, overload 
Over-under voltage, overload 
Inverse time-current 
interruption 
Current limited, timed 
interruption 

Generator control unit j 

1 

Solid-state sensors j 

Solid-state sensors 

RCC&'s, thermal circuit breakers, fuses 
Mil-Spec solid state RPC's 

i 


] Denote; non -avionic' equipment; RCCO-Remote control circuit breakers,- RPC— remote power controllers 
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7.4 APPROACH TO INCORPORATE CONTROL AND DISPLAY CONCEPT 

This section describes (1) the changes to the Phase B CRT formats to 
apply the control and display concept to the baseline system and (2) the system 
changes in the DPS, GN§C, and EPDC subsystems to accommodate the concept. 

The crew function allocations, crew stations, number of keyboards and 
CRT's, and display of flight path monitoring by dedicated mechanical instru- 
ments are retained from the NR-SD baseline system. 

7.4.1 CRT Formats 

The control and display formats defined for the Phase B GN§C and EPDC and 
described in section 3.0 were reviewed to determine applicability to the 
shuttle baseline subsystems described in sections 7.3.2 through 7.3.4. 

The GN§C functions handled through the Phase B CRT formats (section 
3.7.4) group into the principal areas of vehicle management, GN§C subsystem 
management (mode, power and redundancy), checkout, caution and warning, 
checklist, and index. Examining these functions in terms of the NR-SD 
baseline system, the principal impact due to the difference between Phase B 
configuration and the NR-SD proposal baseline is in the vehicle management 
and checkout areas. The baseline provides for dedicated mechanical instru- 
ments to perform the ADI and HSI flight path display functions and, hence, 
does not require formats for primary vehicle flight path control; however, 
typical formats are required for backup GN§C flight path control. Format 
deletions and additions are also required to accommodate the deletion of the 
Phase B precision ranging system (PRS) and the addition of horizon sensor, 
TACAN, ILS and dedicated GN§C computers. Checkout and caution and warning 
comprise functions included as performance monitoring in the NR-SD baseline. 

In Phase B fault detection and isolation was accomplished by the on- 
board computer system by appropriate troubleshooting logic routines. In the 
baseline system, fault detection and isolation is crew accomplished using BITE. 
This significantly reduces the format requirements for this function. 

Review of the design approach of the Phase B formats does not indicate 
the need for significant change to adapt to the NR-SD baseline system. The 
two- and three-digit operation codes, symbology and data content per format 
(Table 3-3) are applicable and, in general, the formats require only re- 
drafting to conform to the NR-SD baseline configuration. Table 7-5 is an. 
estimate of the GNfjC format impact of the baseline. 


Table 7-5. GN§C Format Comparison 



Phase B 

NR-SD Baseline 

Index 

1 

1 

Subsystem Management 

12 

14 

Vehicle Management 

15 

15 

Checkout/Performance Monitoring 

7 

4 

Caution and Warning 

_7_ 

_9 

Total Formats 

42 

43 
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The EPDC functions handled through the Phase B CRT formats group into 
the areas of subsystem management, checkout, caution and warning, checklist 
and index. Review of the Phase B formats indicate, with minor exceptions, 
adequacy as designed due to the very close similarity between the NR-SD Phase 
B and NR-SD baseline EPDC subsystems. The greatest change would be adapting 
checkout formats to performance monitoring. 

Storage in mass memory of timeline format and the checklists required 
for flight operations is a feature of the application of the control and 
display concept to the Phase B shuttle vehicle. Both of these features are 
retained in the application of the concept to the NR-SD baseline vehicle. 
Format requirements for checklists and timelines are considered nominally 
equivalent for both configurations. 

7.4.2 Subsystem Changes 

7. 4.2.1 Data Processing and Software 

The baseline data processing and software arrangement, illustrated in 
Figure 7-1, requires certain changes in order to conform with the display 
and control concept under study. The purpose here is to identify and define 
the need for these changes. 

The first significant change is the addition of three subsystem manage- 
ment (SM) computers and supporting equipments: three input/output buffer 

units; two additional mass memory tape units; and a multitude of command 
decoders. These added equipments and their rearrangement are presented in 
Figure 7-6. 

The addition of these equipments and ultimate rearrangement of functions 
is based on the system reliability criteria for fail-operational, fail-safe. 
The application of these requirements comes about as a result of the concept 
under study which dictates the replacement of hardwired cockpit switches and 
controls with keyboard inputs and an interactive CRT display-to-operator 
interface. That is, the functions performed under computer control at the 
subsystem management station become critical and therefore must meet the 
system reliability goals. This implies a minimum of triple redundancy; i.e., 
three independent means of performing subsystem management functions. The 
choice of adding three additional computers over that of integrating into 
the MDE's is based on the conflict of dedication. That is, only one MDE 
could be dedicated to GNqC without having to perform other functions. Thus, 
with the addition of SM computers, a rearrangement of functional allocations 
is also in order. 

The first logical rearrangement of functions (and thereby changes in 
software), other than performance monitoring, involves the GN§C backup compu- 
tations. These, along with those for performance monitoring, are removed 
from the MDE processors and placed in the SM computers. The function of 
performance monitoring is integrated with the added requirement for command 
and control or in essence combined to effect the display formats described 
earlier in this report. The SM program (software) functions and corres- 
ponding memory size and speed estimates are given in Table 7-6. 
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Figure 7-6. Data Processing and Software Rearrangement 






Table 7-6. SM Computer Program Functional Requirements and Memory Estimates 


FUNCTION 

SIZE § (SPEED) 

j Executive 

j Utility Routines, Input/ 

! Output, Tables, Data Pool 

Scheduling 

900 

Crew Displays 

Execute Input Commands, 
Read Requested Meas 
Data Tables 

750 

... 

Performance Monitoring, 
Limit/Status Chk, Fault 
Annunciation 

t ■ , 

2,400 

1 Command Execution Routines 

... .1,500 

! Measurement Routines 

2,000 

Backup GN§C 

Steer to displays, get- 
home guidance and 
navigation 

2,950 

(33.1) 

Program Loader 

Tape Memory Load on 
Crew Request 

150 

Peak Memory Loading 

10,650 

j 

I Memory Size 

16,384 

Speed KADS 
Size 32-bit Words 

50% Reserve 
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One of the obvious advantages in the rearrangement is the resulting 
commonality generated between the four MDE's studied. That is, the MDE's are 
configured to have identical hardware including their I/O's. Furthermore, 
since the only function performed by the MDE's is that of display processing, 
identical software is used at all four stations (commander, pilot, center 
console, arid subsystem management station). The functions performed and 
memory and speed estimates are given in Table 7-7. The functions performed 
are listed in the form given for the baseline. A further functional break- 
down of the memory estimates and a comparison with Phase B is given in 
Table 7-8. 

Relative to the rearrangement described, it is assumed (without further 
study) that the MDE's servicing the mission specialist station have identical 
hardware and software between them. Furthermore, it is assumed that their 
functional and memory requirements are the same as baseline. 

The only relationship between the MDE's servicing GN$C and SM functions 
and the MDE's serving the payload functions is the ability to act as repeaters. 
This capability assumes no dependency of software and is for convenience only. 

The mass memories are triplicated for the same reliability reasons as 
the SM computers. The tape units are under control of the MDE's. Each unit 
will store all of the formats and all of the supporting software. Fault 
detection of erroneous data is performed by the requesting computer by voting 
on the input data. 

7. 4. 2. 2 GN$C 

This section describes the changes to the baseline Guidance, Navigation 
and Control subsystem necessary for the implementation of the control and 
display concept under study. All of the changes are in conformance with the 
rearrangement described in 7. 4. 2.1. In addition, the requirements for 
any supporting software will be mentioned. 

Before describing the various changes to the GNSC subsystem, the added 
requirements imposed by the format for the display and control concept are 
highlighted. 

One of the purposes of this concept is to allow the operator (s) the 
capability to command and control the subsystems' functions through a keyboard/ 
CRT interface thereby significantly reducing the number of required cockpit 
switches. Ml of this involves interaction between the operator (s) and the 
display subsystem. To provide this capability, the formats are designed to 
display (1) the status or condition of the subsystem, unit, sub-unit, sub- 
assembly, device, etc., under command; (2) any supporting measurement data; 
and (3) the last command issued to the device. Furthermore, the display 
subsystem in combination with the GN§C subsystem must be capable of accepting 
keyboard inputs in conformance with the various formats and translating these 
into the required commands. All of these are to be integrated with the 
baseline GN&C subsystem. The need for a bi-directional data link between the 
GN$C computers and the MDE's (modular display subsystem) is first emphasized. 


7-17 



Table 7-7. SM & GNfjC MDE Program Functional Requirements £ Memory Estimates 


SM, BACKUP GN§C AND GN$C 



FUNCTION 

SIZE AND (SPEED) 

SM 

BU GN8C 

GN$C 

Executive 

Subroutines, input/output, 
data pool, tables 

400 

400 

400 

Crew station displays 

4,650 

4,650 

4,650 

Input/output conversions, 
formats, tables, display 
services, time share GN§C, 
PMC and backup GN£C 

(6.0) 

(6.0) 

(6.0) 

Program loader 

Tape memory load on crew 
request 

150 

150 

150 

Peak Memory Loading 

5,200 

5,200 

5,200 

Main Memory Size 


8,192 



(Memory in 32-bit word equivalents 
Speed in KAOS) 
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Table 7-8. MDE - Estimated Processor Storage Sizing 


FUNCTION 

0 B 

CONCEPT 

NR-SD BASELINE MODIFIED 

EXEC 

400R 

400R 

KYBD 

700R 

500R 


800T 

30 OT 

UPDATE 

600R 

500R 


100T 

50T 

I/O 

600R 

1500R 


100T 

SOT 

SELF-TEST 

300R 

20 OR 

UTILITY 

600R 

600R 

TABLES 

1000R 

- (MOVES TO COMPUTER GROUP) 

REFRESH BUFFERS 

1500Y 

500X 

MASS MEMORY CONTROL 

_ 

500R 


— ... 

100T 

EST. PEAK LOADING 

6700 

5200 


R: resident 

T: transient 

Memory jn 32 -bit word equivalents 
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This need is based on the reliability assurance that the appropriate computer 
subsystem receives the desired input keyboard command. To accommodate this, 
all GN§C input commands are required to be boot-strapped through the computer 
performing the command execution and to be verified on the display by the User 
prior to execution. Some additional supporting software for this function 
will be required in the GNSC computers. 

Other software to be added is the supporting software defined as the 
measurement and command execution routines. The measurement routines 
involve the added instructions peculiar to the format on display necessary 
to read and convert the status of the command device and any supporting data. 
The command execution routines deal with those instructions added for the 
purpose of translating and outputting the input keyboard command into a 
format acceptable by the device (command decoders) . 

The last significant software additions involve the routines and storage 
for displaying and memorizing the last command issued by the operator to the 
device. This involves the addition of a two-dimensional matrix used for the 
purpose of recording the state of all of the last commands. Some additional 
overhead is also required with each format in order to keep track of redun- 
dancies between checklists and subsystem formats. 

The memory and speed estimates for the additional software described are 
reflected in Table 7-9. A comparison of these estimates to those for the 
baseline. Table 7-2 } shows that the added requirements use up approximately 
two percent more memory and 4.5 percent more speed. 

The one last ingredient which has been implicitly mentioned is the 
command decoders out at the sub-unit or sensor level and its interface with 
the GN$C processor IOB. The command decoders are considered digital and/or 
discrete in nature and serially interfaced with the processor through the 
IOB. Furthermore, it is assumed that these devices are configured to operate 
with the 3-string technique described by NR-SD. In essence, each of the sub- 
units operating within a GN§C string is provided an independent command 
decoder interfaced with the computer peculiar to that string. 

7. 4. 2. 3 EPDC 

Application of the control and display concept to the EPDC is basically 
replacing dedicated switches and wires to controlled items, typically remote 
controlled circuit breakers and remote power controllers, with command 
signals from the data processing and software subsystem (DPS) keyboards 
through the MDE's, SM computers and command decoders. The revisions to the 
data processing and software subsystem to implement the required DPS capa- 
bility is described in section 7. 4. 2.1 and consists of the addition of 
functions between MDE's and SM computers and resultant software changes. 

The number and deployment of the command decoders are largely a function of 
the requirements of each serviced subsystem. Connection of the command 
decoders into the EPDC is the principal EPDC area of change to accommodate 
the EPDC to the control and display concept. (The data required from the 
EPDC for display are already collected and available via the operational 
flight instrumentation and are adequate to apply the control and display 
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Table 7-9. GN§C Program Functional Requirements § Memory Estimates 


GN&C 

Function 

Size and (Speed) 

Executive 

Data pool, subroutines 
input/out, sequencing, 
scheduling, tables 

3950 

(13.8) 

System status 

Redundancy management 
GN§C, system performance 
monitor, ground checkout 

2600 

(27.0) 

Flight crew displays 
GN$C system status, 
procedures 

900 

(0.8) 

Navigation 

State vector, attitude 
reference 

5850 

(2.1) 

Guidance 

Steering commands, engine 
control, abort 

7500 

(39.5) 

Targeting 

4200 

(19.3) 

Flight control 

TVC , RCS, digital outer loop, 
boost blending 

2950 

(20.1) 

PROgram services 

Uplink, PCM, pre-flight 
system align § calibration, 
interfaces (booster, payload, 
main engine controller, GSE 
interface) 

2700 

(5.0) 

Unmanned orbiter 

Sequencing, calculation for 
autonomous flight 

500 

ro o 
l • •> ) 

Command Execution Routines 

300 

(6.1) 

Measurement Routines j 

150 

(2.0) 

Peak Memory Loading 

31,600 

Main Memory Size 

65,536 


Speed in KADS 100% Reserve 

Size in 32-bit word equivalents 
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concept to the EPDC.) The command decoders to support the EPDC are accordingly 
estimated below. 

The NR-SD hardware utilization list for the baseline configuration identi- 
fies 19 power distribution and control units with control elements planned 
per Table 7-10. Wherever possible, command decoders units are associated 
on a one-to-one basis with subsystem functional loops. On this basis, review 
of the power distribution design including redundancies indicates approximately 
half of the distribution units require two command decoder units. This then 
results in a requirement of 28 command decoders with a requirement for each 
command decoder to handle an average of approximately 8 and a maximum of up to 
12 controlled circuits. 

7.5 PRELIMINARY DESIGN CONSIDERATIONS 

Preliminary design considerations of the hardware added to incorporate 
the control and display concept are described in this section. This hardware 
is low risk current state-of-the-art. Off-the-shelf units could be identified 
for all items except the command decoders and the Input Output Buffer which 
would be tailored to the application. 

7.5.1 MDE/CRT 

A preliminary organization and design of the MDE and CRT configuration 
and its interface with the keyboards, tape units, and GNf|C and SM computers 
were devised. A simplified block diagram depicting a typical MDE/CRT and its 
interface is presented in Figure 7-7. 

The MDE processor is designed to interface and operate simultaneously 
(in real time) with 

1. one of four input keyboards 

2. three mass memory units 

3. three GN§C input/output buffer units 

4. three, one at a time, SM input/output voting units. 

The MDE interface is performed through the use of a direct memory access 
channel. In addition, the MDE can be considered internally interfaced 
through this same channel with the MDE Refresh Controller. A provision of 
2,048 32-bit words is made for the I/O memory. This includes an estimate 
of 512 words for the static and dynamic refresh buffers; 320 words per GNqC 
(total of 960 words since these operate in 3 string) ; 160 words for the 
system management computer; 384 words for transient routines, read from 
mass memory; and 32 words for input commands and control. 

With few exceptions the design of the MDE/CRT is considered identical 
with that described for the second alternate of the Phase B concept (Section 
5.3). The processor is designed to provide and update the refresh memory 
buffers as well as performing the functions of a general purpose computer. 

The function generators are designed to accommodate the symbol, vector, 
circle, vector and angle perturbation, and rotation modes. The CRT elec- 
tronics are designed to operate using the dot matrix technique for symbol 
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Table 7-10. NR-SD Baseline EPDC Control Element Summary 




Control Elements 



Per Box 

Total 

Main DC Dist Boxes (3) 

(3 Contactors 
<2 RPC 
(2 Relays 

7 

21 

Main AC Dist Boxes (3) 

13 Contactors 
(27 RCCB 

30 

90 

Inverter AC Dist Boxes (3) 

{3 Contactors 

3 

9 

Local Pwr Dist Box (6) 

|l5 RCCB 

15 

90 

Fwd Avionics AC Dist Box (1) 

(l Contactor 
(5 RCCB 

6 

6 

Local AC Dist Box (3) 

il Contactor 

6 

18 


(5 RCCB 


234 

Circuits to be controlled by command decoders in EPDC. 
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FIGURE 7-7. MDE/CRT - SIMPLIFIED BLOCK DIAGRAM 




writing and the electromagnetic detection method for vector writing. Refer 
to Section 5 .2 for further details. 

, The exceptions in the design are attributed mainly to the differences 
in the input/output section of the processors. That is, in the Phase B 
concept the processor was required to interface with a data bus rather than 
three GNSC computers and the SM computers; three keyboards. 'rather than one; 
and three refresh logic controllers rather than one (implying up to three 
CRT's rather than one). A preliminary analysis indicates that the data 
rates are reduced by approximately 50K words per second. This assumes an 
update rate of up to 20 times per second and a refresh rate of 50 times per 
second. The memory requirements are basically the same in that the reduction 
in refresh storage is replaced by the increase due to the input block sizes 
from the GN$C computers. That is, since all programs are resident in these 
computers, a complete measurement list is taken on each update and transferred 
to the MDE where sorting and/or voting is performed per the requested format. 
Note, this imposes some additional software on the MDE's and thereby some 
additional memory requirement. These additions, however, are not critical to 
the design. 

In summary, the MDE/CRT design is well within the state-of-the-art and 
is considered less stringent than the designs specified for Alternates A and 
B given for the Phase B concept. 

7.5.2 Command Decoders 

The command decoders are designed to interface the GN§C and SM computer 
outputs with the command and control switching devices at the subsystem level. 

The command decoders are designed to accept serial bit-by-bit inputs 
consisting of an 8-bit word: 4 bits for address, one bit for control, two 

bits for data, and one bit for parity. Normally, the 4-bit address is used 
to select one of 16 possible 2-state logical switching drivers; however, 
in the event the control bit is set, the adjacent least significant driver 
is also selected and both set in accordance to the two bits used for data. 

The latter is used to control 3-state switches (e.g., auto, off, or on); 
otherwise, the address is unique and only one drive is set (2-state). 

Built-In Test Equipment consisting of monitoring the outputs of the 
switch drivers is made available to the controlling computer. A preliminary 
block diagram of a typical command decoder is presented in Figure 7-8. 

7.5.3 SM Computers 

The subsystem management computers are designed to perform all of the 
logical decisions and arithmetic computations necessary to the functions of 
performance monitoring, backup GN$C, and command and control, the latter 
being in conformance with the concept under study. 

The SM computer is considered to consist of a processor unit and an 
input/output buffer unit. The processing unit is a general-purpose digital 
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Figure 7-8. Simplified Command Decoder Block Diagram 



computer and is identical to those used by the modular display electronics. 

The unit is basically a 16-bit parallel machine capable of performing single 
and double precision arithmetic. The basic characteristics of the processor 
are the same as those described in Section 5.0, Table 5-4, "Basic Processor 
Characteristics," with the following exceptions. The memory capacity is 
increased from 8K to 16K and the processor unit by itself is considered as 
having an I/O consisting only of a parallel direct memory access channel. 

The input/output buffer (IOB) unit serves as the interface between the 
processing unit and all of the other subsystems involved. In this capacity 
the IOB performs the function of signal conditioning and converting and that 
of fault detection by voting on the output signals. The input section of 
the IOB unit consists of three independent input signal converters and con- 
ditioners, each interfaced through a multiplexer with one of the three SM 
processor units. The processing units (under software control) operate on 
the same input data (assuming no errors or faults) and provide an output to 
each of the three voters. The voters then weigh the data and under normal 
conditions output the master computer data. The first non-compare, if not 
master, results in Cf)W annunciation; if the master is at fault, output is 
enabled from non-master and the master is disabled. For second non-compares, 
all results are held and operator uses BITE to select good computer. A 
simplified block diagram illustrating the signal flow through the SM computer 
complex is given in Figure 7-9. 

7.5.4 Mass Memory Storage 

The number of tape units required for the mass memory storage media and 
the estimated storage capacity are increased over that given for the baseline. 
The increase referred to here deals only with the MDE's associated with the 
GN§C and subsystem management functions and not with the payload handling 
and management. 

The number of tape units referred to is increased from one to three in 
order to conform with the reliability criteria fail-operational, fail-safe. 
This requirement is a dictate of having to store the many various command 
and control formats necessary to the implementation of the concept. The 
added units referred to here are shown in Figure 7-6. 

The increase in the estimated storage capacity over that of the 
baseline is simply due to the added number of formats required for the 
concept under study. The formats estimated for use here, and thereby in- 
fluencing the mass memory size, were derived from those used for the Phase B 
concept. The results of the estimate are presented in Table 7-11 and demon- 
strate the need for a capacity of 408,000 words per unit including a 50 
percent design margin. 

7.6 SUMMARY AND CONCLUSIONS 

Application of the control and display concept to the NR-SD baseline 
requires the addition of major items of hardware and software. Three sub- 
system management computers, two tape decks and a large quantity (estimated 
as 230) of command decoders are required to achieve the desired capability 
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Figure 7-9. SM Computer Complex 


INPUTS 


SERIAL 


PARALLEL. 


I/O B 


-v T >i BUFFER/ PARALLEL I 

v, 

BUFFER j 


n 


DC ANALOG I 


y 

B C | : 
1"TT 




H MUX 


AC ANALOG- 
DISC RETE- 


jB C 
!B C 

TV'T- 


>• MUX A/D S BUFFER/ PARALLEL 


| * i 


OUTPUTS 


CD u 

CD I 


I 

^ I 


CD 

( 2 ) 


CD 

(n) r 


C§W; 


— 1 - 


| 

-c - • 


- SERIAL ! 


INPUT CONVERTER A 
INPUT CONVERTER B 

INPUT CONVERTER C 


OUTPUT 

VOTERS 


IN- 


LINE 
-DRIVER ■ !-• 

! U) ! 


| SERIAL j 
j LINE U 
I DRIVER 


(A) 


L_ 


( 2 ) 


(B) 


Jr : 


•’ SERIAL 
I LINE 

j DRIVER 

! (N) 


(C) 


J 



7-28 



Table 7-11. Mass Memory Storage Estimate 



NO. OF 

FORMATS 

* STORAGE REQMT 


0 B 

NR-SD 

Baseline Modified 

Checklist 

180 

180 

163,000 

Subsystem Management 

130 

132 

59,000 

Technical Management 

22 

12 

8,000 

Checkout Formats 

61 

0 

0 

Caution § Warning 

60 

60 

19,000 

Timelines 

22 

22 

6,000 

Indices 

24 

24 

4,000 




259,000 

Baseline estimated rqmts. 

(GN$C MDE 

+ BU GNSC + 

PM) ~ 13,000 



Total Est. 

= 272,000 



S0% Margin 

= 136,000 



Total Reqmt 

408,000 


*Sized for 32-bit words. 
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with a reliability commensurate with vehicle requirements. Software is 
required for the added computers as is augmentation of the GNf|C computer 
software. Also, a significant increase in system engineering integration 
effort is required for command decoder integration into the controlled 
subsystems . 

Alternate mechanizations examined to simplify the approach invariably 
tended toward a centralized data processing subsystem with data bus as 
typified by the Phase B designs. However, the approach was considered not 
admissible under the NASA RFP requirements that lead to the NR-SD baseline. 

While application of the control and display concept to the NR-SD base- 
line is technically feasible, a major problem arguing against application is 
the significant cost and complexity increase resulting from the additional 
hardware and software. While a reduction in dedicated switches and wiring 
is realized, control panel space is not critical in the shuttle. 

The control and display concept has considerable merit as a man- 
machine interface for a centralized digital computer controlled system; 
however, application of the concept to a system where a control interface 
with a digital computer is not pre-existent requires hardware and software 
additions resulting in cost and complexity increases that appear to preclude 
incorporation of the concept. 

The control and display concept does not appear attractive for the 
NR-SD baseline shuttle vehicle. 
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8.0 


SOURCE DOCUMENTS 


In accordance with Section k.5 of the contract statement 
of work, the following listing of source documents utilized 
during the contract pei’iod of performance is provided. 
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1 . 


Development of Space Shuttle Vehicle Crew Workload Criteria for 
Systems Monitoring - Appendices A thru F. Sperry Rand Corporation 
1971; for Marshall Space Flight Center 

A. Mission Porfile and events summary charts 

B. Subsystem operating descriptions 

C. Crew operating requirements 

D. Validating experiments 

E. Off-nominal and emergency cases 

F. Subsystems simplification and comparative flight workloads 

2. Development of Space Shuttle Vehicle Crew Workload Criteria for 
Systems Monitoring - Appendix G. Sperry Rand Corporation, 1971; 
for Marshall Space Flight Center 

A. Boo ster/Orb iter per function workloads (scan freq., dwell time, 
deviation) 

( 1) Two -man 

(a) Normal 

(b) Off-nominal 

(c) Emergency 

(2) One-man crew 

(a) Normal 

(b) Off-nominal 

(c) Emergency 

3. Development of Space .Shuttle Vehicle Crew Workload Criteria for 
Systems Monitoring - Appendix H. Sperry Rand Corporation, 1971? 
for Marshall Space Flight Center 

A. Orbiter per function workloads (scan freq., dwell time, deviation) 

( 1 ) Two -man 

(a) Normal 

(b) Off -nominal 

(c) Emergency 

(2) One-man crew 

(a) Normal 

(b) Off -nominal 

(c) Emergency 

h. Development of Space Shuttle Vehicle Crew Workload Criteria for 
Systems Monitoring - Appendix I. Sperry Rand Corporation, 1971? 
for Marshall Space Flight Center 

A. Boost er/Orbiter Total Workloads (Pilot, Copilot) 

5- Development of Space Shuttle Vehicle Crew Workload Criteria for 

Systems Monitoring - Appendix J. Sperry Rand Corporation, 1971? f° r 
Marshall Space Flight Center 

A. Orbiter total workloads (Pilot, Copilot) 
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6. Avionics Subsystem. Grumman -Boeing,, Phase B Pinal Report, no date. 

A . Overview 

B . Guidance and Navigation 

C . Flight Control 

D . Data Management 

E. Instrumentation 

F. Telecommunications and Air Traffic Control 

G. Displays and Controls 

H. Avionics Subsystem Design 

7- AVIONICS, Displays and Controls. McDonnell -Douglas , E0395 • Phase B 
Final Report, June 1971 

A . Summary 

B . Requirements 

C. Subsystem Description and Rationale 

D. Subsystem Implementation Studies 

E. Built-in Test 

F. Ground Support Equipment (GSE) 

8. Avionics Subsystem Group. North American Rockwell Space Division, 

SD 71-11^-2(2), Phase B Final Report, no date 

A. Avionics Trade Study Summary 

B. Guidance, Navigation and Control (GN & C) 

C . Data and Control Management 

D. Displays and Controls 

E . Communications 

F. Instrumentation 

G. Power Subsystem Group 

9. Avionics Requirements Documentation. TRW Internal Letter, January 1971 

A. Introduction (contains eriticality of functions) 

B. Avionic System Requirements 

C. Guidance and Navigation Subsystem Requirements 

D. Communications ana Navaias Subsystem Requirements 

E. Data Management Subsystem 

10. Functional and Performance Requirements Specification - Space Shuttle 

Avionics System. NASA Manned Spacedraft Center MSC-04075 REV., July 1971 

A. Guidelines, Constraints and Common Requirements 

B. Data Management Subsystem Requirements 

C. Guidance, Navigation and Control (GN&C) Subsystem Requirements 

D. Communication and Tracking Subsystem 

E. Avionics Displays and Controls Subsystem 

F. Power Distribution and Control (PDC) Subsystem 

G. Electronic/Electrical Ground Support Systems Requirements 
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11. Integrated Displays and Controls Trade Study. North American Rockwell 

Space Division, Internal Letter SSP-IE-71-053 • (CS-2.3.2.4 - 15048) 

A. Introduction 

B . Study Approach 

C. Conclusions and Recommendations 

D. Integration Concept and Hardware Approach 

E. Briefing Charts 

F. Study Plan and Control Sheets 

G. Supporting Data 

(1) Appendix A - Selection Criteria and Display - Control Synthesis 

(2) Appendix B - A/N Display Trade-Off Study 

(3) Appendix C - Flight Station Integration 

(4) Appendix D - Caution arid Warning Subsystem 

12. Configuration and Sequencing Control Study. North American Rockwell 
Space Division, Internal Letter SSP- IE -71-021, March 1971- (CS-2. 3-2.1 - 
15021) 

A . Introduction 

B. Definitions 

C . Study Approach 

D. Conclusions 

E. Redundancy Management 

F. Local Automation Hardware 

G . Backup Data 

H. Crew Workload Analysis (Briefing Charts) 

I. Cost 

J. Study Plan and Trade Study Control Sheets 

13. Control Display Unit DLU-B Functional Specification. Collins, no date 

A. CDU I/O Function - Diagnostic IPL Sequence 

B. CDU i/O Function - Preflight NAV Test 

C. Control/Display Unit: Route Definition/initialization 

D. Control/Display Unit: Capability During the Navigate Mode 

E. Control/Display Capability During an In-Flight FDSU Access and 
Flight Plan Assembly 

1.4. Space Shuttle Avionics Subsystems - Associate Contractor For Electronics 
Statement of Work, April 1971- NASA. 

A. Purpose and Scope 

B. Program Description 

C. Technical Description 

D . Program Management 

E. Support Requirements 

F. Systems Reliability and Quality Assurance 

G. Appendix A - Space/Shuttle Orb 1 ter/Boosier Performance Measurement 
Specification 
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15. Space Shuttle, Crew Station Review No. 2. North American Rockwell 
Space Division. Report SW 1-13, 2 April 1971. 

16. Space Shuttle Request for Pioposal. NASA. No. 9-BC421-67-2-40P, 

March 1972 . 

17. Space Shuttle Technical Proposal, Vol. III. North American Rockwell 
Space Division. Report SD 72-SH-50-3, May 1972. 

18. Apollo Operations Handbook, Command and Service Modules J-Series 
Missions, CSM 112 through 114, Vol. 2 Operational Procedures, 25 March 
1971. 

19. Apollo 13 Guidance and Navigation Summary, AC Electronics Division of 
General Motors Corporation. 

20. Operations Plan for Phase C/D Volume II Orbiter, SD 71-103-2, 

25 June 1971. 
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